应使用Windows 8.3短文件名（如C:\PROGRA~1\JAVA~1\jdk-17.0.1）设置JAVA_HOME，而非带空格路径或加引号的长路径，以确保所有Java工具链正确识别JDK。
Java环境变量中带空格的路径直接报错
Windows下把JDK装在C:\Program Files\Java\jdk-17这类含空格路径里，JAVA_HOME一设就失效——命令行执行java -version提示“不是内部或外部命令”，或者Maven、IDEA反复报找不到javac。
根本原因不是引号没加，而是Windows环境变量解析时，对引号的处理极其有限：系统级变量（如JAVA_HOME）本身**不支持用双引号包裹路径**，哪怕你写了"C:\Program Files\Java\jdk-17"，系统也会原样传给子进程，而多数Java工具链（如java.exe启动脚本）根本不会主动去掉外层引号，导致路径识别失败。
- 别在
JAVA_HOME里写带引号的路径，纯属白忙 - 检查
PATH里是否重复拼接了%JAVA_HOME%\bin——如果JAVA_HOME本身已错，整个链路就断了 - 临时验证方法：在CMD里执行
echo %JAVA_HOME%，看输出是否干净、无引号、无乱码
用8.3短文件名绕过空格限制
Windows为每个长路径自动生成兼容性短名（如PROGRA~1对应Program Files），这是最稳定、无需额外配置的解法，且所有Java工具都认。
先用dir /x查真实短名：打开CMD，cd到C:\，运行dir /x，找到PROGRA~1（通常是Program Files），再进该目录继续查Java文件夹的短名（常见是JAVA~1或JDK-17~1）。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
JAVA_HOME应设为类似C:\PROGRA~1\JAVA~1\jdk-17.0.1（注意：末尾不要加\bin） - 确保
PATH中包含%JAVA_HOME%\bin，而不是硬编码路径 - 修改后必须重启所有终端/IDE，旧进程不会自动读取新环境变量
PowerShell或Git Bash里仍出错？检查shell自身路径解析
即使JAVA_HOME设对了，PowerShell或Git Bash启动的子进程可能因自身转义规则误判路径——比如把\当转义符，或把空格当参数分隔符。
这不是Java的问题，是shell环境变量透传机制的副作用。典型现象：CMD里java -version正常，但PowerShell里报The term 'java' is not recognized。
- 在PowerShell中运行
$env:JAVA_HOME确认值是否正确（不含引号、无多余空格） - Git Bash用户需检查
/etc/profile.d/java.sh或~/.bashrc里是否手动加了引号或错误export - 避免在shell配置里写
export JAVA_HOME="C:\Program Files\Java\jdk-17"——双引号+空格=必挂
IDEA/Eclipse里Java路径显示正常但编译失败
IDE的SDK配置界面能显示带空格的JDK路径，不代表它底层调用时真能用——尤其当你用Maven插件或外部构建工具时，它们往往绕过IDE封装，直读系统JAVA_HOME或PATH。
这时候IDE里看着绿勾，实际mvn compile却报Cannot run program "javac"，本质还是环境变量没生效到子进程。
- 在IDE终端（Terminal标签页）里手动执行
where java，确认返回的是你预期的JDK路径 - IntelliJ用户要检查
Help > Edit Custom Properties里有没有覆盖idea.jdk，优先级高于系统变量 - Gradle项目务必确认
gradle.properties里没硬编码org.gradle.java.home指向错误路径
空格路径本身不难解决，难的是不同工具链对环境变量的读取时机、作用域和转义规则各不相同——改完JAVA_HOME，得挨个验证CMD、PowerShell、IDE终端、Maven、Gradle五个地方的实际生效状态。
