Java 长期支持规划：字节码目标与运行环境核对

Java 的版本迁移经常跨越编译器、虚拟机、构建插件与应用框架。选择长期支持版本可以降低频繁切换的成本，但项目仍需回答两个不同问题：代码要用哪个编译器编译，以及产物要在哪个运行时执行。把这两个问题混为一谈，常会导致构建成功而部署启动失败。

建立编译版本与运行版本矩阵

列出开发机、持续集成、打包镜像和生产实例的 JDK 版本，并标明每个位置承担编译还是运行职责。随后检查构建配置中的源级别、目标字节码级别和发布级别设定。若编译器比运行时新，某些新 API 可能被误用；若目标字节码设置不当，旧运行时可能在加载类时直接失败。用一个小程序打印运行时属性并在各环境执行，是确认矩阵是否真实生效的直接方法。

模块边界与反射调用要重点复测

较新的运行时通常会更明确地执行封装边界。项目若依赖反射访问内部类、修改启动参数或使用较旧的字节码增强工具，升级后可能出现访问错误。应全文检索相关启动参数和反射入口，并在集成测试中覆盖对象映射、代理生成、序列化和测试替身等场景。遇到警告时，先确认调用是否依赖非稳定接口；能改为公开 API 的，应优先改造而不是长期保留宽松参数。

构建插件与注解处理器不能忽略

Java 项目经常把兼容性问题交给构建插件暴露。升级前可先检查编译插件、测试执行器、代码生成器、静态分析工具和注解处理器的支持范围。对多模块工程，先从最底层模块开始构建，逐层观察错误，避免顶层失败掩盖真正的第一处不兼容。若依赖库已发布针对候选 JDK 的说明，应以实际构建和测试结果验证，不应只依据间接转述。

标准库变化需要看语义，不只看签名

日期时间、集合、网络客户端、字符集和并发工具的接口即使保持可编译，也可能在边界条件下呈现不同表现。建议构造固定时钟、极端日期、空集合、大对象和超时取消等用例，比较旧新环境输出。对于依赖默认字符集或默认时区的代码，应显式指定设置后再比较，以免环境差异被错误归因于 JDK 更新。

发布时保持可诊断性

在启动日志中记录运行时版本、构建产物版本和关键启动参数；在健康检查中覆盖数据库连接、消息连接及核心配置加载。先运行少量实例并观察一段时间，再逐步替换。长期支持计划、补丁可用性与框架兼容范围会改变，执行迁移时请查阅当期发布方文档和所用框架的维护说明。

良好的 Java 迁移不是一次性跨版本，而是用清晰矩阵把编译、测试和运行的责任分开验证。