用户变量与系统变量区别，Java配置最佳方法

应根据使用范围选择：仅当前用户使用则设用户变量，多账户或系统服务需用则设系统变量；JAVA_HOME必须指向JDK根目录，PATH中需添加%JAVA_HOME%\bin且置于开头以避免版本冲突。

Windows 上 JAVA_HOME 该设在用户变量还是系统变量？

取决于谁要用 Java —— 如果只有当前用户运行 java、javac 或启动 IDE（如 IntelliJ），设在用户变量就够了；如果多个账户要跑 Maven 构建、Jenkins Agent、或 Windows 服务依赖 Java，则必须设在系统变量。

常见错误是：只在用户变量配了 JAVA_HOME，但用管理员权限运行的命令行或服务读不到，结果报 java is not recognized 或构建失败。

• 系统变量对所有用户 + 系统级进程可见；用户变量只对当前登录用户及其启动的进程有效
• 如果同时存在同名的用户变量和系统变量，用户变量会覆盖系统变量（仅对该用户生效）
• JAVA_HOME 的值必须是 JDK 根目录（如 C:\Program Files\Java\jdk-17.0.2），不能带 \bin

PATH 中要不要加 %JAVA_HOME%\bin？加在哪？

要加，而且必须加 —— 否则 java、javac 命令找不到。但位置很关键：它应该放在 PATH 开头，或至少在其他旧版 Java 的 bin 路径之前。

典型翻车场景：系统里装过 JDK 8 和 JDK 17，PATH 里先写了 C:\Program Files\Java\jdk1.8.0_291\bin，再写 %JAVA_HOME%\bin，结果无论 JAVA_HOME 指向哪，执行的永远是 JDK 8 的 java。

• 修改 PATH 时，优先用变量引用（%JAVA_HOME%\bin），别写死路径，方便后续切换 JDK
• 用户 PATH 和系统 PATH 是拼接关系（用户在前），所以用户级 PATH 里放 %JAVA_HOME%\bin 就能覆盖系统级旧路径
• 改完 PATH 后，**必须新开命令行窗口**，旧窗口的环境变量不会自动刷新

IDEA / Eclipse 为啥不认你刚配好的 JAVA_HOME？

因为它们通常不继承系统 Shell 的环境变量，尤其是通过开始菜单或桌面快捷方式启动时 —— Windows 下这类启动方式默认不加载用户环境变量（某些版本甚至跳过系统变量）。

最稳的解法不是反复重启 IDE，而是显式指定 JDK 路径：

• IntelliJ：File → Project Structure → Project → Project SDK → 点 “+” 添加 JDK，选 JAVA_HOME 对应目录
• Eclipse：Preferences → Java → Installed JREs → Add → Standard VM → Next → JRE home 填 JAVA_HOME 路径
• Gradle/Maven 项目还可能单独配置 org.gradle.java.home 或 maven.compiler.source，这些优先级高于环境变量

Linux/macOS 用户容易忽略的等效操作

没有“用户变量/系统变量”之分，但有加载时机差异：~/.bashrc（仅交互式非登录 shell）、~/.bash_profile（登录 shell）和 /etc/profile（全局）的执行顺序不同。

常见问题：在 ~/.bashrc 里设了 JAVA_HOME，但用 sudo ./gradlew 或 systemd 服务启动时失效 —— 因为 sudo 默认不继承当前 shell 环境，systemd 更是完全隔离。

• 对单用户长期使用，推荐写入 ~/.bash_profile（macOS Terminal 默认读它）或 ~/.profile（Ubuntu 图形登录后读）
• 需要被 sudo 继承？加 Defaults env_keep += "JAVA_HOME" 到 /etc/sudoers（用 visudo 编辑）
• systemd 服务必须在 .service 文件里显式写 Environment="JAVA_HOME=/path/to/jdk"

环境变量这层看似简单，真正卡住人的从来不是“怎么配”，而是“谁在什么时候读哪个值”。尤其跨权限、跨进程、跨 GUI 启动时，变量根本不在你以为它在的地方。