为什么Java程序员喜欢抱着Java8，守着mybatis写xml？（不用orm） ？

这个现象在中国Java后端圈确实非常普遍（尤其是中大厂和传统互联网/金融/政府项目），甚至到2025–2026年仍然是大主流技术选型。核心原因可以归纳为下面几点，基本是历史路径依赖 + 现实生产约束 + 文化偏好的叠加结果：

为什么还抱着Java 8？

1. 稳定性压倒一切
   Java 8 是第一个长期支持版（虽然Oracle官方早已不提供免费更新，但各种OpenJDK发行版如Zulu、Adoptium、龙井、Tencent Kona等都长期维护Java 8），很多公司内部把“不出事”放在第一位。
2. 生态最成熟、最便宜的版本

• Spring Boot 2.x 主力版本就是基于Java 8
• 无数中间件、组件、Agent（skywalking、arthas、sentinel、nacos、seata……）最稳的版本都是Java 8
• 升级到11/17/21要重新验证一堆第三方jar、压测、改代码（尤其是用了Unsafe、反射、代理的组件），人力成本巨大

1. 很多老项目根本动不了
   动一次几百万行代码，动辄半年到一年没人敢碰，业务不敢停，出了问题没人背锅。

为什么守着MyBatis + XML？

1. SQL掌控感最强（这是最核心的心理因素）
   绝大多数Java程序员（尤其是工作3–10年的）对Hibernate/JPA的HQL/Criteria/自动生成SQL极度缺乏安全感，怕“写着写着就多查了字段/多表关联/隐式笛卡尔积/N+1”。
2. 性能红线 + 复杂查询场景
   国内互联网/金融项目普遍有以下特点：

• 报表类查询极多（left join 10+张表、group by、window函数、复杂条件）
• 经常需要走索引提示、强制走某条索引
• 要写union、cte、存储过程调用
• 批量操作要控制批次大小、要看到实际执行的SQL MyBatis在这方面几乎无敌，JPA/Hibernate要么写原生SQL（那还不如MyBatis），要么性能调优极其痛苦。

1. 历史路径依赖 + 人才密度

• 阿里从iBatis时代就开始大规模使用 → 淘宝/支付宝/钉钉/饿了么/优酷等一堆公司抄阿里技术栈
• MyBatis招聘成本最低、简历最多、面试最容易对齐
• 团队里总有1–2个“SQL老人”，他们一反对用JPA，整个团队就继续MyBatis了

1. “全自动ORM”在国内被打成筛子了
   很多人用过早期MyBatis-Plus / JPA / Spring Data JPA后，遇到下面这些痛点就彻底回MyBatis了： 场景 JPA/Hibernate常见痛点 MyBatis写法 复杂多表查询 HQL写崩 / Criteria写到吐 / 最后还是nativeQuery 直接写SQL，清晰可控 性能瓶颈排查 很难一眼看出实际SQL 日志里就是最终SQL 批量插入/更新 性能一般，容易出脏数据问题 foreach + batch 动态SQL复杂逻辑 很难写（case when / 多层if） 标签/OGNL/三元/脚本语言 DBA审核SQL 基本不可能审核自动生成的SQL XML/SQL文件可以直接给DBA看

总结一句话

国内Java后端主流技术栈停留在“Java 8 + Spring Boot 2.x + MyBatis XML + MySQL”这个组合，本质上是：

“在当前人力成本、业务稳定性要求、复杂查询占比、团队SQL掌控偏好、人才市场供给”这几个约束条件下，它就是性价比/风险比最高的局部最优解。

想打破这个循环，通常需要下面几者至少满足其一：

• 公司强力推动技术升级（字节、某些大厂新项目已经大量Java 17/21 + jOOQ / Kotlin Exposed / MyBatis-Plus）
• 团队里有很强悍的架构/ORM爱好者能把JPA玩出花来
• 新项目从0开始，且业务场景不以复杂查询为主

你现在项目是用这一套吗？还是已经开始往别的方向走了？