结论是：JAVA_HOME路径含空格、末尾带反斜杠、PATH顺序不当、终端未重启或环境变量作用域错误，导致java命令不识别；须用无空格路径、正确格式、置顶PATH、全新终端验证。
直接说结论：报“java 不是内部或外部命令”这类错误，90% 与 JAVA_HOME 路径格式、PATH 中的引用方式、或 CMD/PowerShell 进程未刷新有关，和 JDK 是否装对无关。
为什么 JAVA_HOME 设对了，java -version 还不认？
根本原因不是变量没建，而是路径被截断或拼接失败。Windows 在解析 %JAVA_HOME%\bin 时，若 JAVA_HOME 值含空格（如 C:\Program Files\Java\jdk-17），系统会把它切分成 C:\Program 和 Files\Java\jdk-17 两段——cmd.exe 不支持带空格路径的变量展开，且不接受引号包裹（"%JAVA_HOME%\bin" 是无效写法）。
- 必须把 JDK 安装到无空格路径，例如
C:\jdk17或C:\Java\jdk-17 -
JAVA_HOME值末尾不能带反斜杠：C:\jdk17\❌，应为C:\jdk17✅ - 避免中文、括号、&、# 等字符，哪怕只是文件夹名里有也不行
- 验证方法：在 CMD 中运行
echo %JAVA_HOME%，输出必须是干净、完整、无换行的路径
PATH 里写了 %JAVA_HOME%\bin，但 where java 找不到或指向旧版本
这是 PATH 搜索顺序和残留路径共同导致的。Windows 按照 PATH 列表从上到下查找可执行文件，一旦某条路径里有 java.exe，就立刻命中，不再继续。
- 用
where java查看实际命中的路径，如果第一行不是你新配的%JAVA_HOME%\bin下的，说明前面有更高优先级的旧 JDK 路径 - 打开“环境变量”编辑界面，在系统变量的
Path列表中，把%JAVA_HOME%\bin这一项**拖到最顶部**（不是随便插进去） - 不要手动写死绝对路径（如
C:\Program Files\Java\jdk-8\bin），这种写法无法随JAVA_HOME变动而更新，也容易遗漏 - 如果旧 JDK 已卸载但 PATH 里还留着它的
bin，请手动删掉整行
CMD 里 java -version 有效，但 PowerShell 或 IDE 里无效
因为环境变量继承机制不同：CMD 启动时读取的是用户环境块；PowerShell 默认继承 CMD 的变量，但如果之前执行过 $env:Path += "xxx"，就会污染当前会话；IDE（如 IntelliJ、VS Code）启动时读取的是它首次加载时的环境快照，不会自动感知你刚改的变量。
- 每次修改环境变量后，**必须关闭所有已打开的 CMD / PowerShell 窗口，再全新启动一个**
- VS Code 需要完全退出（右下角托盘也要关掉），再重新打开；否则终端仍沿用旧环境
- IntelliJ IDEA 需在
Help → Find Action → "Registry"中搜索ide.env.reuse，禁用它，才能让新环境生效 - PowerShell 中临时改
$env:Path不影响后续新开窗口，仅限当前会话，别拿它当持久配置
安装完 .msi 包，JAVA_HOME 和 PATH 自动加了，但还是报错
Oracle 或 Eclipse Temurin 的 .msi 安装器确实会自动写入系统变量，但有两个隐藏陷阱：
- 它可能只写了系统级变量，而你的当前用户没有管理员权限，导致 CMD 实际读取的是用户级环境块（此时
JAVA_HOME为空） - 某些安全加固策略（如 Windows Defender Application Control）会拦截环境变量写入，尤其在企业版 Win11 上
- 检查方式：打开“系统属性 → 高级 → 环境变量”，分别看“系统变量”和“用户变量”里是否都有
JAVA_HOME和Path相关项；若有冲突，以用户变量为准 - 稳妥做法：不管安装器有没有自动配，都手动补全用户变量里的
JAVA_HOME和Path条目
最常被忽略的一点：环境变量修改后，连“任务管理器 → 启动”里预加载的 Shell 进程（比如 Windows Terminal 的后台服务）都可能缓存旧值。真要确认生效，唯一可靠动作就是——关掉所有终端，重启一个全新的 CMD，然后只跑三行：
echo %JAVA_HOME% where java java -version
三行输出都符合预期，才算真正落地。别信“我点确定了就应该好了”这种直觉。
