7.1 Java生态全景与选型逻辑

7.1 Java 生态全景与选型逻辑

本节摘要：Java 后端技术栈可以压成一张五层地图：JDK 运行时、框架层、数据访问层、中间件层、观测与交付工具链。本节逐层梳理主流选择与选型判据，讲清 Spring IoC/AOP 解决的真实问题，给出"技术雷达"式的采用决策框架——选型的核心不是追新，是控制坑的归属。

从一个团队的真实困境说起

一个十人团队启动新服务，技术选型会上吵了三周：JDK 用 17 还是 21？Spring Boot 2 还是 3？ORM 用 MyBatis 还是 JPA？网关要不要上响应式？最后项目经理拍板"都用最新的"，结果招聘困难（响应式经验稀缺）、线上问题难查（响应式堆栈不可读）、升级踩坑（Boot 3 的 Jakarta 命名空间迁移）——每一项都是选型时没付的账，连本带利在半年后收回。

反面不是保守，是没有判据。这节的目标就是给出判据。

五层全景图

Java 后端技术栈全景

各层补充几句判断。

运行底座：JDK 版本策略是所有决策里回报最确定的。新项目直接最新 LTS（21，下一站 25）；存量 8 的升级按"每代一两个硬收益"推进：11 的 HTTP 客户端与 var、17 的密封类与 record、21 的虚拟线程与分代 ZGC。虚拟线程尤其值得单独评估——第 4/5 章的 BIO 容量天花板与线程池参数玄学，在它面前直接作废。

框架层：Spring 的统治力不是功能而是默认值——自动装配把"组装"从每项目的手工劳动变成约定。理解它的钥匙是 IoC 与 AOP：IoC 解决"对象依赖谁"的装配问题（依赖注入让第 2 章的组合改造不再需要手工 new 一长串）；AOP 解决横切关注（事务、日志、权限——第 3.3 节的注解三段式在此落地）。Spring Boot 3 的门槛是 Jakarta EE 命名空间迁移（javax→jakarta），老依赖不兼容是主要升级成本。

数据访问层：MyBatis 与 JPA 之争的实质是 SQL 掌控感 vs 研发速度。查询复杂、要调优、团队 SQL 功底好，MyBatis（SQL 可见可改）；CRUD 为主、模型驱动，JPA 省事但 N+1 查询（关联懒加载逐条查）是经典坑——开 SQL 日志抽查是必须的习惯。连接池默认 HikariCP（快且稳），参数怎么配是第 7.3 节的主角。

中间件层：Kafka 与 RocketMQ 的选择看场景（日志流 vs 事务消息），但先问要不要消息队列——异步解耦与削峰是真收益，多一个中间件的多运维成本也是真支出。网关层的响应式（WebFlux）只在高并发长连接场景有不可替代性，普通业务用传统阻塞栈 + 虚拟线程更可维护。

选型的四个判据

把争论变成评分的框架：

1. 团队可运维性（权重最高）：凌晨三点坏掉时，在场的人会不会修？一个没人懂的酷炫组件是负资产
2. 社区与生命周期：issue 响应、发布节奏、与 JDK 版本的兼容承诺——选的是未来五年的合作方
3. 可退出性：抽象层（接口隔离）能不能让这个组件被替换？越靠近业务核心越要留退路
4. 坑的归属清晰：引入前问"这个库的坑谁兜底"——文档质量、堆栈可读性、调试工具，决定事故时的 MTTR

我的默认立场偏保守：核心链路选无趣但被验证过的技术，创新放在边缘模块。生态位的"无聊技术"（boring technology）不是贬义——它意味着坑被前人踩完、招聘池大、文档全。要试新技术，用独立小服务隔离爆炸半径，跑半年再决定推广。

⚠️ 常见坑：把"技术雷达"当任务清单，每期都要引入点什么。选型清单的默认动作是"不引入"，引入需要理由，不引入不需要理由。

💡 关键直觉：生态的价值是坑的外包——框架与中间件把通用坑（第 4、5 章那些）做成默认正确的配置。你要付的钱是理解它的抽象，付不起理解成本时，外包反而是新的坑源。

最后补一段关于版本升级的节奏感。很多团队的 JDK 与框架版本停留在多年前的 LTS，不是不想升，是怕升——依赖面太大，回归成本吓人。可行的策略是把升级做成常态而非事件：每次 LTS 发布后，在非核心服务上先跑一轮兼容性验证，把不兼容点（如 Jakarta 命名空间、移除的 API）整理成清单，再按服务重要度逆序推开。常态化的升级每次只差一两个版本，风险碎片化；积攒多年的大跳版则是一锤子买卖，一锤子砸不动就永远停在原地。生态层的健康度，最终体现为"跟上社区的速度"，而不是某一次英勇的大迁移。

防坑清单

• 新服务最新 LTS；存量升级按版本硬收益排期，不追非 LTS
• 响应式只在长连接高并发不可替代场景采用，评估可维护性成本
• JPA 开 SQL 日志防 N+1；MyBatis 防动态 SQL 拼接的注入面
• 中间件引入先算运维成本，退出路径写进设计文档
• 每个第三方依赖登记"坑的归属"：谁维护、文档在哪、怎么排查

本节要点回顾

• 五层地图：底座、框架、数据访问、中间件、观测交付，各有主流默认值
• JDK 策略：新项目最新 LTS，存量按硬收益升级，虚拟线程重新定义 IO 容量
• Spring 钥匙：IoC 管装配，AOP 管横切，Boot 的价值是默认值
• ORM 之争：SQL 掌控感 vs 研发速度，N+1 与注入面各自设防
• 选型判据：可运维性 > 社区生命周期 > 可退出性 > 坑的归属

最后补一段关于版本升级的节奏感。很多团队的 JDK 与框架版本停留在多年前的 LTS，不是不想升，是怕升——依赖面太大，回归成本吓人。可行的策略是把升级做成常态而非事件：每次新 LTS 发布后，先在非核心服务上跑一轮兼容性验证，把不兼容点整理成清单，再按服务重要度逆序推开。常态化升级每次只差一两个版本，风险被切成小片；积攒多年的大跳版则是一锤子买卖，一锤子砸不动就永远停在原地。生态层的健康度，最终体现为"跟上社区的速度"这种日常能力，而不是某一次英勇的大迁移。把升级频率写进团队季度目标，比在架构评审里争论"要不要升级"有效得多——争论说明已经落后，落后越多越不敢动，这才是技术栈老化的真实机制。

下一节聚焦生态的第一大坑：依赖冲突。

如果只能带走一句话，那就是：选型时对每项技术都问一句"它的坑我团队兜得住吗"。兜得住就用，兜不住就换成熟的替代品——生态足够大，几乎总有第二个选择。技术审美是奢侈品，交付能力才是硬通货。