关键在于避免全局硬编码JAVA_HOME，改用SDKMAN!等会话级工具动态管理JDK，确保各终端会话独立、无残留，并让IDE和构建工具信任shell环境而非越权覆盖。
关键不是“防止被覆盖”，而是不依赖全局硬编码的 JAVA_HOME。很多软件（比如某些安装包、IDE 启动脚本、Docker 构建流程）会主动重设或忽略你设在系统/用户级的 JAVA_HOME，导致它失效或冲突。真正稳定的做法是绕过“全局覆盖”问题，改用分层控制机制。
优先用会话级动态管理工具
SDKMAN!（Linux/macOS）或 jdk-switcher（macOS Homebrew）这类工具，不修改系统环境变量，而是通过 shell 函数劫持 java 和 javac 命令，并在当前终端会话中临时设置 JAVA_HOME。这意味着：
- 每个新终端都是干净会话，不受其他软件启动时污染
- 执行
sdk use java 17.0.2-tem后，which java和$JAVA_HOME立即同步更新 - 关闭终端后自动还原，无残留
避免在系统/用户级配置 JAVA_HOME
Windows 的“系统属性 → 环境变量”或 Linux 的 /etc/environment、~/.bashrc 中硬写死 JAVA_HOME=/usr/lib/jvm/java-17-openjdk，等于给所有进程发一个强制指令。一旦某款软件（如旧版 Eclipse 启动器、某些 CI 脚本）读取并信任这个值，而你的项目实际需要 Java 11，就会立刻报 UnsupportedClassVersionError。
建议做法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 把
JAVA_HOME从系统/用户变量中彻底删除 - 只保留
PATH包含通用工具（如/usr/local/bin），不包含任何 JDK 的bin - 让 JDK 切换完全由 SDKMAN!/asdf 控制
IDE 和构建工具要“信任 shell，不越权覆盖”
IntelliJ、VS Code 或 Maven 容易成为覆盖源。需手动检查以下几处：
- IntelliJ：关闭 Settings → Build → Build Tools → Maven → Import → Use project JDK for build process，否则它会强行用 Project SDK 覆盖你 shell 里切好的 JDK
-
Maven：确认
pom.xml中<maven.compiler.source>17</maven.compiler.source>和<maven.compiler.target>17</maven.compiler.target>显式声明，不要只靠java.version属性——Maven 不读JAVA_HOME决定编译目标版本 -
Gradle：检查
gradle.properties是否有org.gradle.java.home，如有，应删掉或设为auto，让它跟随当前 shell
验证是否真被“覆盖”了
别只信 java -version，要交叉比对：
- 新开一个终端 → 运行
echo $JAVA_HOME和which java - 在同一终端运行
mvn -v | grep "Java home"，看 Maven 实际加载的是哪个 JDK - 在 IntelliJ 里打开 Terminal，再执行以上命令——如果结果和外部终端不一致，说明 IDE 自己起了隔离环境
只要这三者一致，就说明没被覆盖；不一致，说明某处配置越权干预了。
