环境变量配置失效主因是路径顺序错误、缓存未刷新、多层覆盖及执行上下文不一致：path从左到右匹配，需将%java_home%\bin置顶；已打开终端/ide须完全重启；system32或/usr/bin中的旧java会优先生效；多shell配置文件（如.zshrc与.zprofile）需正确source以避免覆盖。
环境变量配置失效，通常不是改错了，而是系统没按你预期的方式读取。关键在路径顺序、缓存残留、多层覆盖和执行上下文这四点。
PATH中路径顺序决定谁生效
Windows 和 Linux 都按 PATH 中从左到右的顺序查找命令。比如你设置了 JAVA_HOME 指向 JDK 17，但 PATH 里 Oracle 自带的 JDK 8 路径排在前面，那 java -version 就永远显示 8。
- Windows：打开“系统属性 → 高级 → 环境变量”，在系统 PATH 中把 %JAVA_HOME%\bin 移到最前面
- Linux/macOS：检查 ~/.bashrc、~/.zshrc 或 /etc/profile，确保 export PATH="$JAVA_HOME/bin:$PATH" 这类语句中 $JAVA_HOME/bin 在 $PATH 前面
- 验证：运行 which java（Linux/macOS）或 where java（Windows），看返回的是不是你期望的路径
System32 或 /usr/bin 下的“幽灵”可执行文件
Windows 的 C:\Windows\System32\java.exe、Linux 的 /usr/bin/java 是常见干扰源。它们不读 JAVA_HOME，直接硬编码版本，优先级还很高。
- Windows：用管理员权限运行 cmd，执行 del C:\Windows\System32\java.exe（以及 javaw.exe、javaws.exe）
- Linux：检查 /usr/bin/java 是否是符号链接（ls -l /usr/bin/java），如果是，且指向旧 JDK，可删除后重建软链，或用 update-alternatives --config java 统一管理
- 注意：删前先确认这些文件不是系统关键组件所依赖的，一般开发机上可安全处理
终端/IDE/服务进程不继承新变量
改完环境变量后，已打开的终端、IDE、后台服务不会自动刷新——它们启动时读取的变量快照已固化。
- 终端：关闭所有窗口，重新打开；不要只执行 source ~/.zshrc 就以为生效了（它只影响当前 shell，子进程如 vim、git 可能仍用旧 PATH）
- IDE（如 IntelliJ IDEA、VS Code）：必须完全退出再重开；部分 IDE 还需在设置里手动指定 Project SDK，不能只靠系统 JAVA_HOME
- Windows 服务或 Linux systemd 服务：需要重启服务本身，甚至重启整个系统才能确保所有守护进程加载新变量
多 Shell 配置文件互相覆盖
你的 ~/.bashrc 可能被 ~/.bash_profile 覆盖，而 ~/.zshrc 又可能没被 ~/.zprofile 加载——尤其在 macOS Catalina 及以后默认用 zsh，但 GUI 应用常走 ~/.zprofile。
- 检查当前 shell 类型：echo $SHELL
- 确认哪个文件实际生效：ps -p $$ 看是否为 login shell；login shell 默认读 ~/.zprofile（zsh）或 ~/.bash_profile（bash）
- 稳妥做法：在 ~/.zprofile（或 ~/.bash_profile）末尾加一行 source ~/.zshrc（或 source ~/.bashrc），保证统一加载
