Java多版本共存时JAVA_HOME不可全局硬编码，应通过SDKMAN!/asdf等工具动态管理，并确保Maven/Gradle配置、IDE设置、Docker镜像及子进程环境均与项目所需JDK版本严格一致。
Java多版本共存时JAVA_HOME不能全局硬编码
直接把JAVA_HOME指向某个JDK路径（比如/usr/lib/jvm/java-17-openjdk），会导致所有终端、IDE、构建工具强制使用该版本，一旦项目依赖Java 8或Java 21就立即报错——UnsupportedClassVersionError或编译失败。这不是环境变量“没配对”，而是它被设计为单值全局开关，无法按项目切换。
真正可行的方案是：让JAVA_HOME保持未设置或设为空，改用工具链动态控制实际使用的JDK。
- Linux/macOS下优先用
update-alternatives（Debian/Ubuntu）或jdk-switcher（macOS Homebrew）做系统级软链接管理，但仅用于默认值兜底 - 开发时必须依赖
SDKMAN!或asdf这类多版本管理器，它们通过shell函数劫持java、javac命令，并在当前shell会话中动态重设JAVA_HOME - IDE（如IntelliJ）需关闭“Use project JDK for build process”类选项，否则会覆盖shell中已生效的
JAVA_HOME
Maven项目中java.version和maven.compiler.source/target必须匹配
Maven不会自动读取系统JAVA_HOME来决定编译目标字节码版本。即使你用SDKMAN!切到了Java 17，若pom.xml里还写着javax.xml.bind）导致运行时报NoClassDefFoundError。
关键检查点：
立即学习“Java免费学习笔记（深入）”；
-
17），不能只靠java.version属性 - Spring Boot项目若使用
spring-boot-starter-parent，其父POM已内置java.version，此时要确认该父版本是否支持你的JDK（例如Spring Boot 3.x要求Java 17+） - 执行
mvn -v看Maven实际调用的Java路径，再对比which java，二者不一致说明Maven启动脚本绕过了shell环境变量
IDEA中Project SDK和Project language level不是一回事
很多人以为只要在File → Project Structure → Project里选了JDK 21，项目就完全跑在Java 21上——其实这只是告诉IDE用哪个JDK做语法校验和代码补全。Project language level单独控制IDE内部的语法高亮、Lambda提示等行为，而真正的编译和运行取决于两个独立配置：
-
Settings → Build → Compiler → Java Compiler → Target bytecode version：决定.class文件生成的版本，必须与maven.compiler.target一致 -
Run → Edit Configurations → Templates → Application → JRE：指定运行时使用的JDK，若为空则 fallback 到Project SDK，但可被单独覆盖 - Gradle项目还需检查
gradle.properties中org.gradle.java.home是否指向正确JDK，否则Gradle Daemon可能复用旧进程，导致System.getProperty("java.version")返回意外版本
Docker构建中硬编码FROM openjdk:17-jdk-slim不够安全
镜像标签如openjdk:17-jdk-slim实际指向的是某次构建的快照，下次docker pull可能拉到带安全补丁的新版本（如从17.0.1升到17.0.2），而某些老项目依赖特定JDK小版本的JNI行为或GC参数，默认升级后出现OutOfMemoryError或线程挂起。
生产环境应锁定完整版本号：
FROM openjdk:17.0.2-jdk-slim
更稳妥的做法是用sha256摘要固定镜像：
FROM openjdk@sha256:7e9a4a3c9b4d5a7f8e6b1a2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e
同时，在Dockerfile中显式导出JAVA_HOME并验证：
RUN echo $JAVA_HOME && java -version
避免因基础镜像内部路径变更（如从/usr/lib/jvm/java-17-openjdk-amd64变成/opt/java/openjdk）导致后续脚本中$JAVA_HOME/bin/java失效。
最常被忽略的其实是Shell子进程继承问题：用nohup、systemd或CI脚本启动Java服务时，子shell往往不加载~/.sdkman/bin/sdkman-init.sh，导致JAVA_HOME为空，最终退化到系统默认JDK。这种场景下，必须在启动命令前显式source初始化脚本，或直接写死绝对路径——环境隔离不是配一次就完事，而是每个执行上下文都得重新确认。
