JAVA_HOME必须指向JDK根目录（含bin、lib、jre等子目录），不可为jre或bin子目录；验证需执行echo $JAVA_HOME、ls $JAVA_HOME确认结构完整，并用java -XshowSettings:properties -version比对java.home路径是否一致。
确认 JAVA_HOME 指向的目录结构是否完整
很多问题其实不是没装 JDK，而是 JAVA_HOME 指错了位置——比如指向了 jre 子目录、bin 目录，甚至指向了 .jdk 包本身而非 Contents/Home（macOS）。
执行：echo $JAVA_HOME → 看输出路径ls -l $JAVA_HOME → 必须能看到 bin、lib、conf（或 jre）、include 等标准子目录ls $JAVA_HOME/bin/javac → 必须存在且可列出，不能报 “No such file”
常见错误路径举例：
✘ /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk（缺 /Contents/Home）
✘ /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home/jre（错进 jre）
✔ /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home
which java 和 which javac 是否指向同一 JDK
如果两个命令返回不同路径，说明环境变量 PATH 里混进了多个 JDK 的 bin，或者系统软链接被覆盖（如 macOS 的 /usr/bin/java 是系统代理，实际可能转发到旧版本）。
检查方式：which javawhich javacreadlink -f $(which java)（Linux）或 ls -la $(which java)（macOS）→ 追踪到底层真实路径
关键判断点：
• 两者输出的父目录应完全一致（即都来自同一个 $JAVA_HOME/bin）
• 若 javac 找不到，但 java 能运行，大概率是 PATH 里只加了 JRE 的 bin，或 JAVA_HOME 配错导致 $JAVA_HOME/bin 根本没生效
验证 JDK 目录下关键文件是否有执行权限
OpenJDK 官方包解压后一般权限正常，但手动移动、sudo 操作或挂载卷（如某些 NAS 或容器映射）可能导致 bin 下文件丢失 x 权限，表现为 Permission denied 错误，即使路径正确。
快速检查：ls -l $JAVA_HOME/bin/javals -l $JAVA_HOME/bin/javac
预期权限至少含 -rwxr-xr-x（即所有者有执行权）。若显示 -rw-r--r--，需修复：chmod +x $JAVA_HOME/bin/java $JAVA_HOME/bin/javac $JAVA_HOME/bin/jar
（建议顺手加上 jar、jshell 等常用工具）
注意：
• 不要用 chmod -R 755 $JAVA_HOME/bin，某些脚本（如 jspawnhelper）依赖特定权限位
• 如果 JDK 在 NFS 或 APFS 加密卷上，还可能受扩展属性影响，可用 xattr -l $JAVA_HOME/bin/java 查看
用 java -XshowSettings:properties -version 反向验证加载路径
这个命令会打印 JVM 启动时读取的所有系统属性，其中 java.home 是 JVM 实际使用的根路径，它不依赖 PATH 或 JAVA_HOME，而是由二进制自身内嵌逻辑或启动器决定的，非常适合作为“真相校验器”。
执行：java -XshowSettings:properties -version 2>&1 | grep "java.home"
输出类似： java.home = /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home
对比这个值和你设的 $JAVA_HOME：
• 一致 → 路径配置可信
• 不一致 → 说明终端里 java 命令根本没走你配的 JDK，可能是：
– PATH 中有更高优先级的其他 java（比如 Homebrew 装的）
– shell 配置未生效（zsh 用户忘了 source ~/.zshrc）
– IDE 或脚本中硬编码了 JAVA_HOME
