这是专栏第 12 篇，也是这一轮 JDK 系列收官。
我想把这篇写成一份可以直接执行的迁移路线，而不是“升级口号”。
一、为什么我把迁移单独写一篇
很多团队不是不知道新特性好用，而是卡在这几个现实问题：
- 升级路径不清，担心一步跨太大；
- 兼容问题不可预期，怕线上风险；
- 没有回滚方案，发布窗口不敢开。
我自己做过多次迁移后，一个结论很稳定：
升级失败通常不是技术做不到，而是迁移策略不结构化。
二、版本信息与迁移路线（LTS 节点）
- Java 8：2014 年发布，当前多数存量系统基线；
- Java 11：2018 年 LTS，
HttpClient等标准能力完善； - Java 17：2021 年 LTS，语言与运行时能力明显增强；
- Java 21：2023 年 LTS，虚拟线程正式可用（JEP 444）。
我最推荐的是三段式：
8 -> 11：先跨到第一个 LTS，解决基础生态问题；11 -> 17：吃到语言特性和运行时改进；17 -> 21：吃到虚拟线程等新能力，并保持 LTS。
这条路线的优势是每一步跨度可控，问题定位更容易。
三、每一跳我会重点关注什么
8 -> 11
- Java EE / CORBA 模块移除（JEP 320）；
- 内部 API 访问（
sun.*）收紧； - 构建工具链（Maven/Gradle/插件）版本升级；
- 容器环境下的 JVM 参数重新校准。
11 -> 17
- 新语法/新 API 可逐步落地（
record、sealed等）； - 运行时性能与 GC 行为再评估；
- 安全基线和 TLS 默认行为核对。
17 -> 21
- 虚拟线程与并发治理能力引入评估；
- 预览特性（如 Structured Concurrency）治理策略；
- 与现有框架、监控、压测模型联动升级。
四、适配场景 / 不适配场景
适配场景：
- 中大型后端服务，维护周期长；
- 现有 JDK 8 技术债明显，排障和性能优化成本高；
- 团队能提供至少一个迭代的迁移窗口。
不适配场景：
- 近期有高风险业务大版本发布，发布窗口不足；
- 构建链和依赖仓库不可控，无法同步升级；
- 业务方要求“零回归承诺”但又不接受灰度和回滚。
五、从 JDK 8 升级时，我会先做这 9 个前置动作
1) 建立组件清单
把服务依赖拆成：框架、数据库驱动、RPC、监控、日志、构建插件。
先确认每个组件支持到哪个 JDK 版本。
2) 跑jdeps和非法反射扫描
提前识别内部 API 依赖，避免升级后运行期爆炸。
3) 固定基线指标
至少记录：
- 启动耗时；
)
