应根据使用范围选择：仅当前用户使用则设用户变量，多账户或系统服务需用则设系统变量；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。
立即学习“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"
