java环境变量无语言级作用域，属操作系统配置：系统变量需管理员权限、对所有用户生效；用户变量仅限当前用户；会话级设置仅对当前终端有效；java_home定位jdk，path决定命令执行，二者缺一不可。
Java 开发环境搭建中，环境变量的权限和生效范围直接影响命令能否执行、工具能否识别 JDK，甚至决定 Maven、IDEA 或 Tomcat 能否正常启动。它们不是“设完就生效”的简单操作，而是受操作系统用户层级、会话生命周期和变量作用域严格约束的系统级配置。
谁有权设置？系统变量 vs 用户变量
Windows 下环境变量分两类，权限和影响范围不同：
- 系统变量：需管理员权限才能修改，对本机所有用户生效。JAVA_HOME 和 PATH（全局 Java 命令）强烈建议设为系统变量，否则普通用户或后台服务（如 Tomcat 作为 Windows 服务运行）可能读不到。
- 用户变量：当前登录用户专属，无需管理员权限即可编辑，仅对该用户当前及后续登录会话有效。适合临时测试或多版本隔离场景（比如某项目必须用 JDK 8，而主开发用 JDK 21），但不推荐作为主力开发环境配置。
改完为什么没反应？生效时机很关键
环境变量不是实时广播的，修改后不会自动刷新所有已打开的程序：
- 命令提示符（cmd）、PowerShell 等终端窗口：必须关闭并重新打开才能读取新变量。旧窗口里执行
echo %JAVA_HOME%或java -version仍显示旧值。 - IDE（如 IntelliJ IDEA、Eclipse）：启动后读取一次环境变量，重启 IDE 才能生效。部分 IDE 提供“Reload project”不解决此问题，必须彻底退出再启动。
- Windows 服务（如以服务方式运行的 Tomcat）：需重启对应服务**，而非仅重启应用**。有时还需重启“Windows Management Instrumentation”等依赖服务。
- GUI 程序（如 VS Code）：若从开始菜单或桌面图标启动，通常继承的是登录时的环境快照；推荐从新开的 cmd 中用
code .启动，确保加载最新变量。
JAVA_HOME 和 PATH 的作用边界要分清
两者职责明确，不能互相替代，越权设置反而引发问题：
-
JAVA_HOME 只负责“定位”：它是一个路径字符串，不参与命令查找。Maven、Gradle、Tomcat 等工具通过读取 JAVA_HOME 自行拼接
%JAVA_HOME%\bin\java.exe或加载%JAVA_HOME%\lib\tools.jar。设错路径（比如指向了 JRE 或 bin 目录）会导致这些工具直接报错“JAVA_HOME not set”或“No tools.jar found”。 -
PATH 只负责“执行”：它告诉系统去哪找可执行文件。必须包含
%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/macOS）。如果只设 JAVA_HOME 却漏掉 PATH，你在 cmd 里敲javac会提示“不是内部或外部命令”。 - CLASSPATH 已基本弃用：现代构建工具和 JVM（Java 9+）默认处理类路径，手动配置易覆盖默认行为，引发 NoClassDefFoundError。除非维护 20 年前的老项目，否则留空即可。
多 JDK 共存时的权限与切换逻辑
一台机器装多个 JDK 很常见，切换本质是变更 JAVA_HOME 指向，并确保 PATH 引用一致：
- 修改 JAVA_HOME 后，PATH 中的
%JAVA_HOME%\bin会自动生效——前提是 PATH 里写的是变量引用，而不是硬编码路径（如C:\jdk8\bin）。 - 不同用户可各自设置不同的 JAVA_HOME（用户变量），互不影响；但若设为系统变量，则所有用户统一使用该版本，权限上需管理员操作。
- 某些企业环境禁用用户变量修改权限，此时必须联系 IT 部门调整系统变量，或使用脚本在项目根目录下临时设置（
set JAVA_HOME=...），仅对当前 cmd 会话有效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
