这是专栏第 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 - 11Java 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) 固定基线指标至少记录：启动耗时；