核心内容摘要
十八而志，风华正茂：汤姆的十八岁青春指南
这个现象在中国Java后端圈确实非常普遍尤其是中大厂和传统互联网/金融/政府项目甚至到2025–2026年仍然是大主流技术选型。
核心原因可以归纳为下面几点基本是历史路径依赖 现实生产约束 文化偏好的叠加结果为什么还抱着Java 8稳定性压倒一切Java 8 是第一个长期支持版虽然Oracle官方早已不提供免费更新但各种OpenJDK发行版如Zulu、Adoptium、龙井、Tencent Kona等都长期维护Java 8很多公司内部把“不出事”放在第一位。
生态最成熟、最便宜的版本Spring Boot
x 主力版本就是基于Java 8无数中间件、组件、Agentskywalking、arthas、sentinel、nacos、seata……最稳的版本都是Java 8升级到11/17/21要重新验证一堆第三方jar、压测、改代码尤其是用了Unsafe、反射、代理的组件人力成本巨大很多老项目根本动不了动一次几百万行代码动辄半年到一年没人敢碰业务不敢停出了问题没人背锅。
为什么守着MyBatis XMLSQL掌控感最强这是最核心的心理因素绝大多数Java程序员尤其是工作3–10年的对Hibernate/JPA的HQL/Criteria/自动生成SQL极度缺乏安全感怕“写着写着就多查了字段/多表关联/隐式笛卡尔积/N1”。
性能红线 复杂查询场景国内互联网/金融项目普遍有以下特点报表类查询极多left join 10张表、group by、window函数、复杂条件经常需要走索引提示、强制走某条索引要写union、cte、存储过程调用批量操作要控制批次大小、要看到实际执行的SQLMyBatis在这方面几乎无敌JPA/Hibernate要么写原生SQL那还不如MyBatis要么性能调优极其痛苦。
历史路径依赖 人才密度阿里从iBatis时代就开始大规模使用 → 淘宝/支付宝/钉钉/饿了么/优酷等一堆公司抄阿里技术栈MyBatis招聘成本最低、简历最多、面试最容易对齐团队里总有1–2个“SQL老人”他们一反对用JPA整个团队就继续MyBatis了“全自动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基本不可能审核自动生成的SQLXML/SQL文件可以直接给DBA看
总结一句话国内Java后端主流技术栈停留在“Java 8 Spring Boot
x MyBatis XML MySQL”这个组合本质上是“在当前人力成本、业务稳定性要求、复杂查询占比、团队SQL掌控偏好、人才市场供给”这几个约束条件下它就是性价比/风险比最高的局部最优解。
想打破这个循环通常需要下面几者至少满足其一公司强力推动技术升级字节、某些大厂新项目已经大量Java 17/21 jOOQ / Kotlin Exposed / MyBatis-Plus团队里有很强悍的架构/ORM爱好者能把JPA玩出花来新项目从0开始且业务场景不以复杂查询为主你现在项目是用这一套吗还是已经开始往别的方向走了