xbatis 1.9.9-M7 发布：7个版本迭代后

一个基于 MyBatis 的 ORM 框架，在 GitHub 上攒了 1.2k star，最近 30 天下载量涨了 340%。这个数字放在 Spring Data JPA 面前不够看，但放在国产 ORM 的语境里，它意味着一件事：有人正在用另一种方式回答"Java 数据库操作到底该多简单"这个问题。

1.9.9-M7 改了什么：从"能跑"到"敢用"的最后一块拼图

这次更新的核心动作可以拆成三组。第一组是稳定性——修复了批量插入时连接池泄漏的 bug，这个问题在 1.9.9-M5 被首次报告，M6 尝试修复但没彻底解决，M7 终于补完。第二组是性能——动态 SQL 的解析缓存命中率从 73% 提到 89%，官方基准测试显示复杂查询场景下延迟降低了 22%。第三组最微妙：他们删掉了三个"看起来有用"的注解，理由是"用户反馈不知道怎么选"。

删掉功能比增加功能更需要勇气。xbatis 的作者在微博解释过这个逻辑：「MyBatis 的痛点不是功能少，是选择多。XML 还是注解？Mapper 接口放哪？二级缓存开不开？每个决定都要花时间，而程序员的时间不是无限的。」

这种做减法的思路贯穿了 xbatis 的 7 个里程碑版本。1.0 时期它叫"mybatis-plus 的替代品"，1.5 开始强调"零配置启动"，到 1.9 系列彻底转向"约定优于配置"——翻译成人话就是：你按常规写法来，框架自动猜你想干什么；非要自定义也行，但得额外写一行声明。

MyBatis 生态的裂缝：为什么不是官方升级？

MyBatis 3.5.16 今年 1 月发布，更新日志里主要是 bug 修复和驱动适配。这个节奏让一部分开发者焦虑：核心团队似乎在"维护模式"里躺平了。xbatis 的 README 里有一句很扎眼的描述——「基于 MyBatis 但不受其版本节奏约束」，明摆着是吃准了这种焦虑。

但"不受约束"是有代价的。xbatis 1.9.9-M7 的发布说明里埋了一条警告：「与 MyBatis 3.5.15+ 存在已知兼容性问题，建议锁定 3.5.14」。换句话说，它既依赖 MyBatis 的底层，又和最新版 MyBatis 打架。这种张力在技术选型时会被放大——你是要"稳定的老东西"还是"激进的新东西"？

国内某电商中台的技术负责人跟我聊过这个 dilemma。他们 2023 年试过 xbatis 1.7，结论是"省代码但费脑子"——省的是样板代码，费的是排查问题时要同时看 xbatis 和 MyBatis 两份文档。最后回退了，但留了一个人在社区里盯着更新。「M7 的连接池修复要是早半年出来，我们可能不会退」，这是他的原话。

340% 下载增速背后：谁在偷偷换工具？

Maven Central 的下载统计有个特点：它只计数，不记身份。但结合 GitHub issue 的活跃度和知乎相关讨论的点赞分布，可以拼凑出一个用户画像——工作 3-5 年的 Java 后端，经历过 MyBatis 的完整学习曲线，现在想要"不那么蠢"的重复劳动。

xbatis 的语法糖设计确实瞄准了这个群体。比如它允许这样写：

```java @Select("select * from user where id = #{id}") User getById(Long id); ```

看起来和 MyBatis 一样？区别在隐式转换。如果数据库字段叫 user_name 而 Java 属性叫 userName，MyBatis 需要 @Results 或 resultMap 显式映射，xbatis 默认自动驼峰转换——除非你用 @StrictMapping 关掉它。这种"默认帮你省一步，但允许你改回去"的设计哲学，和 Python 的 "import this" 里那句"显式优于隐式"正好相反。

争议也在这里。GitHub 上有个被点了 47 个 的 issue 质问：「自动转换在重构时就是隐形炸弹，字段改名了编译期不报错，跑到生产环境才炸」。作者的回应是加了一个编译期注解处理器，M7 里默认关闭，M8 计划默认开启。这种"先给糖，再给解药"的迭代节奏，在社区里褒贬不一。

国产 ORM 的窄门：生态位比技术更重要

把 xbatis 放在更大的坐标系里看，它的对手不是 MyBatis，而是 MyBatis-Flex、Fluent-MyBatis 这一批同样做"增强层"的项目。三者的技术路线分化很有意思：MyBatis-Flex 押注 APT（注解处理器）生成代码，Fluent-MyBatis 走链式 API 路线，xbatis 选择对 MyBatis 做最小侵入的包装。

最小侵入意味着迁移成本低，也意味着天花板可见。xbatis 的文档里坦承：「我们不处理连接管理、事务传播、缓存策略，这些交给 Spring 或 MyBatis 自己」。这种边界感在商业上可能是聪明的——不做重资产，只做轻服务——但在技术深度上留下了问号。一个只用 xbatis 的开发者，对 MyBatis 的理解会比原生用户更浅还是更深？

知乎上有个匿名回答被折叠了，理由是"缺乏可靠信息来源"，但内容很有意思：「我们组用 xbatis 半年，省了两千行 XML，但排查一个 N+1 问题花了三天，因为不知道它怎么生成的 SQL」。这个样本不能代表全部，但它提示了一个风险：抽象层越厚，调试时的认知负担越重，除非工具链足够成熟。

M7 的发布说明里有一个容易被忽略的细节：他们开始提供 IDEA 插件的 beta 版，支持从 Mapper 接口一键跳转到实际执行的 SQL。这个功能的优先级被提到 bug 修复之前，说明团队已经意识到"可观测性"是 adoption 的关键瓶颈。

GitHub 上最新一条讨论是关于 2.0 路线图的。有人提议彻底 fork MyBatis 内核，摆脱版本绑定；有人反对，认为那样会失去"基于 MyBatis"的信任背书。作者回复说还在评估，但加了一句：「无论选哪条路，1.x 会维护到 2026 年底」。这个承诺的时间跨度，比很多开源项目的生命周期还长。

你会为了一个省代码的框架，接受可能存在的调试黑箱吗？或者说，当"约定优于配置"变成"约定隐藏配置"，这个 trade-off 的边界应该画在哪？