




JAVA_HOME必须指向JDK根目录(如C:\Program Files\Java\jdk-17.0.1或/usr/lib/jvm/java-17-openjdk-amd64),不可指向bin或jre子目录,否则Maven等工具会因无法识别JDK而启动失败。
JAVA_HOME 必须指向 JDK 的根目录(不是 JRE,也不是 bin 目录),例如:C:\Program Files\Java\jdk-17.0.1(Windows)或 /usr/lib/jvm/java-17-openjdk-amd64(Linux/macOS)。常见错误是把它设成 .../jdk-17.0.1/bin 或 .../jre —— 这会导致 Maven、Gradle、Tomcat 等工具启动失败,报错类似 The JAVA_HOME environment variable is not defined correctly。
java -version 后,再执行 where java(Windows)或 which java(macOS/Linux),然后向上推两级目录(JDK 根目录下一定有 bin、lib、jre 等子目录)
JAVA_HOME 只能指向其中一个;切换版本需手动修改该变量,不能靠 PATH 优先级覆盖Windows 中设置位置不同,生效范围和持久性差异很大。最稳妥的是系统环境变量方式,避免 IDE 或命令行终端读不到。
JAVA_HOME = C:\Program Files\Java\jdk-17.0.1;同时在 PATH 开头追加 %JAVA_HOME%\bin —— 这种方式对所有用户、所有终端(CMD/PowerShell/IDE)都生效set JAVA_HOME=C:\Program Files\Java\jdk-17.0.1 —— 关闭窗口即失效,适合调试$env:JAVA_HOME="C:\Program Files\Java\jdk-17.0.1" —— 仅当前会话有效,且不会被 CMD 继承macOS Catalina 及以后默认 shell 是 zsh,所以改 ~/.zshrc 才能保证终端每次启动都加载;而 /etc/environment 是 Debian/Ubuntu 系统级配置,但部分发行版(如 CentOS)不读它,且不支持变量展开(不能写 PATH="$PATH:$JAVA_HOME/bin")。
~/.zshrc(macOS)或 ~/.bashrc(旧版 Linux)末尾添加:export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH
source ~/.zshrc(或 source ~/.bashrc)才生效;新开终端也会自动加载JAVA_HOME 写进 /etc/profile 除非你确定要全局强制统一(多用户服务器场景才需要)别只信 java -version —— 它只反映 PATH 中的 java 命令路径,和 JAVA_HOME 无关。真正检测变量是否被正确识别,得看依赖它的工具行为。
echo $JAVA_HOME(Linux/macOS)或 echo %JAVA_HOME%(Windows CMD)—— 输出应为完整路径,且不能带空格未引号包裹(Windows 路径含空格时,JAVA_HOME 值本身无需引号,但引用处如 %JAVA_HOME%\bin 会自动处理)mvn -v:输出里必须显示 Java version: 17.0.1 和 Java home: /usr/lib/jvm/java-17-openjdk-amd64 —— 这个 Java home 就来自 JAVA_HOME,不是 java -XshowSettings:properties -version 2>&1 | grep java.home 查到的 JRE 路径JAVA_HOME 一致;否则说明 IDE 没读到该变量(常见于从桌面图标启动,而非终端中执行 idea.sh)java -version 显示 JDK 17,但 Jenkins 构建报 “Unsupported class file major version 61”,根源就是 CI 机器上 JAVA_HOME 指向了旧版 JDK,而构建脚本没显式指定 java 路径。变量这东西,看不见摸不着,偏偏一错就整条链路崩。