升级openjdk后旧项目失败的根本原因是构建与运行环境版本不一致；需分别锁定编译源码/字节码级别、显式配置各运行容器的java_home、使用稳定软链接管理多版本、修正shell脚本中java调用方式。
不能只换一个JAVA_HOME就以为万事大吉。升级OpenJDK后旧项目跑不起来，根本原因不是“新版本不行”，而是构建环境和运行环境被混为一谈——编译用的JDK、打包用的Maven/Gradle、运行用的JVM、甚至CI流水线里启动脚本读取的JAVA_HOME，可能各自指向不同版本，且没人校验一致性。
构建工具必须显式锁定源码兼容级别
Maven或Gradle默认会用当前JDK的最高语言特性编译，哪怕你只是想用JDK 17编译一个JDK 8能跑的jar。不加约束，javac会悄悄启用var、switch表达式等JDK 10+语法，导致旧JVM加载失败。
- Maven中必须同时设置：
<java.version>1.8</java.version>（控制依赖版本）和<source>1.8</source>+<target>1.8</target>（控制字节码版本），二者缺一不可 - Gradle中对应的是
sourceCompatibility = JavaVersion.VERSION_1_8和targetCompatibility = JavaVersion.VERSION_1_8，仅设javaToolchain指定JDK路径不管用 - 验证是否生效：解压生成的jar，用
javap -v ClassName | grep "major version"，JDK 8对应52，JDK 17是61——如果看到61，说明编译配置失效了
运行时JDK切换不能只靠环境变量
很多团队在CI或生产机上改完JAVA_HOME和PATH就认为搞定了，结果Tomcat用新JDK启动，但其内部调用的ant脚本或自定义java命令仍走系统默认，旧项目直接NoClassDefFoundError。
- Tomcat：必须在
bin/setenv.sh（Linux/macOS）或bin/setenv.bat（Windows）中显式写死JAVA_HOME，否则它会忽略系统级变量 - systemd服务：在
.service文件的[Service]段加Environment="JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64"，不能只靠/etc/profile.d/ - Shell脚本：避免直接写
java -jar app.jar，应改为$JAVA_HOME/bin/java -jar app.jar，防止被update-alternatives覆盖
多版本共存时软链接比硬路径更安全
把/usr/lib/jvm/java-8-openjdk-amd64这种带架构和更新号的路径直接写进脚本或配置，等于埋雷——下次OpenJDK 8更新到8u401，路径变成java-8-openjdk-amd64-jdk8u401，所有地方全崩。
- 统一创建稳定软链：
sudo ln -sf /usr/lib/jvm/java-8-openjdk-amd64 /usr/lib/jvm/jdk8，所有服务都引用/usr/lib/jvm/jdk8 - 构建机上可并行维护
/usr/lib/jvm/jdk8、/usr/lib/jvm/jdk17、/usr/lib/jvm/jdk21，按项目需求切换软链目标，而非改环境变量 - CI脚本中用
export JAVA_HOME=$(readlink -f /usr/lib/jvm/jdk8)获取真实路径，避免软链嵌套出错
最常被忽略的一点：旧项目里那些#!/usr/bin/env java开头的Shell启动脚本，它们根本不看JAVA_HOME，只认PATH里第一个java。这类脚本必须重写成#!/usr/bin/env $JAVA_HOME/bin/java，或者用update-alternatives确保java命令本身也指向目标版本——否则，环境变量配得再完美，启动瞬间就掉坑里。
