JAVA_HOME必须指向JDK而非JRE，确认路径末尾为jdkX.X.X_XXX且含bin/javac；PATH中仅保留一个%JAVA_HOME%\bin并置顶；多版本切换推荐SDKMAN!或脚本隔离。
检查 JAVA_HOME 是否指向 JDK 而非 JRE
很多问题根源在于 JAVA_HOME 指向了 C:\Program Files\Java\jre1.8.0_301 这类 JRE 目录，而非真正的 JDK（如 C:\Program Files\Java\jdk1.8.0_301）。JRE 不含 javac、jar 等开发工具，导致命令行报 'javac' is not recognized。
- 在终端运行
echo %JAVA_HOME%（Windows）或echo $JAVA_HOME（macOS/Linux），确认路径末尾是jdkX.X.X_XXX，不是jreX.X.X_XXX - 进入该路径，手动检查是否存在
bin/javac.exe（Windows）或bin/javac（macOS/Linux） - 若用 IDE（如 IntelliJ 或 Eclipse），它们可能绕过系统
JAVA_HOME，但 Maven/Gradle 构建仍会失败——此时必须修复系统级配置
PATH 中不要重复添加 %JAVA_HOME%\bin 多次
PATH 里出现多个 bin 目录（比如同时有 C:\jdk8\bin、C:\jdk17\bin、%JAVA_HOME%\bin）会导致命令解析混乱，java -version 和 javac -version 显示版本不一致。
- 运行
where java（Windows）或which java（macOS/Linux），看返回几条路径；只保留一条，且应与%JAVA_HOME%\bin一致 - PATH 中优先放置
%JAVA_HOME%\bin，并确保它排在其他 Javabin目录之前 - 避免直接把
C:\jdk17\bin写死进 PATH —— 后续切换 JDK 时需同步改两处（JAVA_HOME和 PATH），极易遗漏
IDE 和构建工具是否真正读取了 JAVA_HOME？
IntelliJ 默认忽略系统 JAVA_HOME，用内置的 bundled JDK；Maven 则严格依赖 JAVA_HOME 来定位 tools.jar（JDK 9+ 已移除，但旧插件仍可能尝试加载）。
- Maven 项目执行
mvn compile报错UnsupportedClassVersionError，大概率是JAVA_HOME指向低版本 JDK，而source配置为高版本 - Gradle 的
org.gradle.java.home配置优先级高于JAVA_HOME，若设了该属性，改JAVA_HOME无效 - 验证方式：在项目根目录运行
mvn -v，输出中的Java version必须与$JAVA_HOME/bin/java -version一致
java version "17.0.2" 2022-01-18 LTS Java(TM) SE Runtime Environment (build 17.0.2+8-LTS-86) Java HotSpot(TM) 64-Bit Server VM (build 17.0.2+8-LTS-86, mixed mode, sharing)
多 JDK 共存时，如何安全切换？
靠手动改 JAVA_HOME 和 PATH 容易出错，尤其在 CI/CD 或脚本中。更可靠的方式是使用工具层隔离。
立即学习“Java免费学习笔记（深入）”；
- Windows 可写批处理脚本：
set JAVA_HOME=C:\jdk17 && set PATH=%JAVA_HOME%\bin;%PATH% && mvn clean - macOS/Linux 推荐用
SDKMAN!：sdk use java 17.0.2-tem临时切换，不影响全局环境 - Docker 构建中，务必显式指定基础镜像的 JDK 版本（如
eclipse-temurin:17-jre-jammy），不要依赖宿主机JAVA_HOME
JAVA_HOME 和 PATH 的“顺手一改”——只要其中一处没同步，java 和 javac 就可能偷偷跑在不同版本上。 
