作者注：这不是一篇框架对比评测，是一次关于技术选择背后社会机制的深度反思。基于十余年企业级开发实践，以及一套名为 SimpleDAO（Spring Jdbc Ultra）的框架的生产验证，我们来讨论一个被长期忽视的问题：一个有明显缺陷的技术，为什么能在市场上流行这么多年？

---

为什么一个有明显缺陷的技术能流行？

MyBatis 的流行，不是技术选择的结果，是多重力量共同塑造的现状。它流行，不代表它好。它流行，只说明它在特定历史时期解决了特定问题，然后被惯性推着走了十几年。

我们今天来拆解这背后的力量。

---

一、原生缺陷：从根上就歪了

MyBatis 的流行建立在六个系统性缺陷之上。这些缺陷不是偶然的设计失误，是范式层面的结构性错误。

缺陷一：SQL 编写白盒，SQL 执行黑盒

MyBatis 让你在 XML 里看到 SQL，觉得“这很透明”。但执行时你完全不知道框架做了什么——七层执行链路、动态代理、拦截器链、缓存层，像一个黑盒。

• 想加数据权限？写拦截器。
• 想加脱敏？写拦截器。
• 想改 SQL 执行？写拦截器。
• 想追踪 SQL 执行链路？你在日志里看到的是 7 层嵌套调用栈。

每一个拦截器都要求你学习 MyBatis 的内部对象模型：BoundSql、MappedStatement、ParameterHandler、ResultSetHandler……你花时间学习的不是业务逻辑，是框架的内部实现细节。这不是扩展，是用学习框架内部结构来换取一点点控制权。

缺陷二：XML 标签拼字符串——用残缺的语言干 Java 擅长的事

Java 里你写 StringBuilder、append、replace、format、String.join，有 IDE 补全、有断点调试、有类型检查。XML 里你写 <if>、<foreach>、<include>、<sql>，标签、属性、OGNL、#{}、${}，五种东西混在一个文件里。

你做的是同一件事——拼接字符串。但 Java 里你可以调试、可以复用、可以抽取方法，XML 里你只能靠眼睛检查、靠脑补运行结果。这不是“分离”，是把同一件事换了一个更差的工具去做。

缺陷三：OGNL——把业务逻辑塞进配置文件

你在 XML 里写：

<if test="name != null and name != ''">
    AND name LIKE CONCAT('%', #{name}, '%')
</if>

这不是配置，是程序逻辑。但它用配置文件的语言（OGNL）写成，没有 IDE 调试、没有编译期检查、没有代码跳转。它在 XML 里插入了程序逻辑，又把程序逻辑从 Java 的审查、调试、重构能力中剥离出去。这是一个负优化。

缺陷四：七层执行链路——每次查询都绕远路

StatementHandler、ParameterHandler、ResultSetHandler、Executor、Cache、Interceptor、MappedStatement……你的每次查询都要经过 7 层才能到达数据库。性能损耗是其次，最重要的是——查问题的时候，你要理解这 7 层里每一层在做什么。

缺陷五：31 类自造异常——中间商赚差价

Spring JDBC 只有 2-3 类异常。MyBatis 有 31 类。你花时间学的不是“数据库出了什么问题”，是“框架的哪一层又炸了”。你多学 10 倍异常类型，多读 10 倍框架内部类源码，才能回到 Spring JDBC 的起点。

缺陷六：单表思维——背离 RDBMS 的本质

RDBMS，第一个单词是 Relation（关系）。企业级开发中，单表场景占比极低。MyBatis-Plus 所谓的“单表解决 80% 业务”，是行业最大的谎言之一——它只覆盖了那 10% 的单表场景，却假装覆盖了 80% 的业务。你被它骗了。

---

二、心理层面：认知防御——越痛苦越维护

你投入了大量时间学 XML、学 OGNL、学 <if> 和 <foreach>、学 resultMap 和 association、学拦截器机制、学 31 类异常。你为 MyBatis 付出了太多，于是你产生了认知防御：

• “我花了三个月学它，它不可能不好。”
• “大家都用它，它不可能有问题。”
• “如果真的不好，为什么还有这么多人在用？”

你被自己的投入绑架了。 你开始本能地为它辩护，把它的缺陷解释成“必要复杂度”，把它的冗余解释成“企业级”，把它的漏洞解释成“你不懂用”。这不是你的错，这是心理学上经典的**“投入越大，越难放弃”**机制。

---

三、社会层面：羊群效应——大厂用，所以它是对的

“大厂在用、面试在考、社区都在讨论”，你就默认为它是标准。没人敢质疑、敢突破。你把“流行”等价于“正确”，把“面试在考”等价于“应该学”，把“大厂在用”等价于“值得用”。你忘了：

• 流行不代表正确
• 面试在考只说明它足够普及
• 大厂在用，只说明它没有犯致命错误

你用它的理由，不是“它好”，而是“大家都在用”。这是羊群效应。你从众，不是因为你判断它好，是因为判断成本太高，从众最省事。

---

四、经济层面：产业链——没人愿意打破既得利益

MyBatis 背后是一条巨大的产业链：

• 培训公司教它，因为教简单的东西收不了高价
• 博主写它，因为它有足够多的问题可以写
• 插件开发者靠它活着——MyBatis-Plus、MyBatis-Flex、MyBatis-TK、MyBatis-Plus-Join
• 书籍作者靠它吃饭——《深入浅出 MyBatis》《MyBatis 从入门到精通》

这条产业链上的每一个人，都是 MyBatis 流行的受益者。 他们不关心 MyBatis 好不好，他们关心 MyBatis 还“够不够流行”。所以他们不断生产内容、不断强化“MyBatis 是标准”的叙事，形成一个自我强化的循环。

---

五、政治层面：选型免责——出了事是框架的问题，不是我的问题

这是技术选型中一个非常隐蔽、但非常强大的力量。团队负责人选择一个流行框架，如果项目出了问题，他可以理直气壮地说：“大家都在用，我们也是跟着行业标准走的，出了问题谁也预料不到。”

但如果你选一个非主流方案，出了任何问题，责任都会指向你：“当时为什么选这个冷门框架？”这种选型免责机制，驱动着大多数技术决策走向趋同，而非走向更优。你不是在选“对的技术”，你是在选“不会被追责的技术”。

---

六、所以，你今天加班写的 XML，其实是在为什么买单？

你为这四个维度的历史惯性买单：

1. 心理惯性：你投入了太多时间学它，无法承认自己的投入是浪费
2. 社会惯性：大家都在用，面试都在考，你跟从了多数
3. 经济惯性：整个产业链都在靠它赚钱，没人愿意打破循环
4. 政治惯性：选错了是框架的问题，不是我的问题

你每天都在为它的缺陷买单：多写 3 倍代码、多学 10 倍语法、多排 10 倍框架内部错误。你加班写的 XML，本质上是在为 MyBatis 的历史惯性买单。而你加的每一行班，都在帮助 MyBatis 撑住“流行”的表面——你在用自己的时间为它的存续续费。

---

技术应该解放你，而不是绑架你

MyBatis 不是解决之道，它是问题本身。它不是解决方案，它是已经被你习惯了的麻烦。而你真正的解决方案，一直就在你手边——Spring JDBC，以及基于它构建的 SimpleDAO。

技术可以更简单，开发可以更愉快，程序员可以早下班。

如果你厌倦了为历史惯性买单，欢迎来试试 SimpleDAO。

---

相关开源地址：

1. 核心框架源码：https://gitee.com/gao_zhenzhong/simple-dao
2. 系统底座：https://gitee.com/gao_zhenzhong/simple-dao-starter
3. 代码生成器：https://gitee.com/gao_zhenzhong/simple-dao-coder
4. 实战案例：https://gitee.com/gao_zhenzhong/simple-dao-demo