必须使用系统环境变量配置JAVA_HOME和Path，因为Maven、Gradle、IDEA等工具默认读取系统级变量；用户变量仅适用于纯CMD下临时demo，且易因路径冲突、未刷新终端或优先级问题导致where java失败或命令不可识别。

为什么不用用户环境变量配OpenJDK

绝大多数情况下，JAVA_HOME 和 Path 必须设为**系统环境变量**，而不是用户环境变量。因为 Maven、Gradle、IDEA、Tomcat、Spring Boot CLI 等工具在启动时默认读取系统级变量；若只配在用户变量里，它们可能根本找不到 JDK，报错如 The JAVA_HOME environment variable is not defined correctly 或 Failed to detect JDK。

只有极少数场景适合用用户变量：比如你只是临时想在自己账户下跑一个 demo，不涉及任何构建工具，且确认所有调用都由当前用户进程发起（比如纯 CMD 下手动 java -jar）。但这种做法不可靠，也不可移植。

用户变量配置后命令行仍报“不是内部或外部命令”

即使你成功在用户变量里设置了 JAVA_HOME 和 %JAVA_HOME%\bin 到 Path，CMD/PowerShell 仍可能无法识别 java 或 javac。常见原因有：

windows-shell

Windows 命令行编码与兼容规范。涵盖 GBK/UTF-8 编码、PowerShell/pwsh 互操作、Python/Node.js、Git 配置及代码生成规则。适用于 Windows 10/11 + MSYS2/Git Bash 环境下的所有命令行操作。

下载

• JAVA_HOME 值末尾多了反斜杠（如 D:\jdk-17\ ❌），应为 D:\jdk-17 ✅
• Path 中该条目被其他旧 JDK 路径覆盖——Windows 按顺序查找，用户 Path 条目排在系统 Path 之后，若系统 Path 里已有 C:\Program Files\Java\jdk-8\bin，它会先被命中
• 没开新终端——用户环境变量修改后，已打开的 CMD/PowerShell 不会自动刷新，必须关闭重开
• where java 输出多于一行，说明路径冲突未清理干净

如果真要用用户变量，必须同步改这三处

仅新建 JAVA_HOME 和往用户 Path 加 %JAVA_HOME%\bin 是不够的。你还得确保：

• 系统变量里的 Path 不含任何硬编码的 JDK bin 路径（如 C:\jdk-11\bin），否则优先级更高
• 用户变量里的 Path 条目中，%JAVA_HOME%\bin 必须放在最顶部（点击“上移”直到第一行）
• 运行 echo %JAVA_HOME% 和 where java 都要返回唯一、正确的结果；若 where java 无输出，说明 %JAVA_HOME%\bin 根本没生效，大概率是路径拼错或变量名写成 java_home（大小写敏感）

真正安全的做法：直接用系统变量

用户变量看似“只影响自己”，实际在 Windows 上容易引发隐性冲突。比如：

• 某些 IDE（如 Eclipse）以服务方式启动，走的是系统上下文
• CI 工具（如 Jenkins Agent）常以系统服务身份运行，读不到用户变量
• PowerShell 的 $env:JAVA_HOME 在不同会话中行为不一致，尤其启用 ConstrainedLanguage 模式时

所以除非你在受控的演示机、测试账户里做一次性验证，否则别绕开系统变量。填错 JAVA_HOME 比用错变量作用域更容易修复——后者的问题往往藏在工具链深处，排查成本高得多。