系统变量对所有用户生效、需管理员权限修改，存于hkey_local_machine；用户变量仅当前用户可见、普通权限可改，存于hkey_current_user；同名时用户变量覆盖系统变量，但管理员进程不继承用户变量。
系统环境变量和用户环境变量的区别在哪
Windows里这两类变量不是“选哪个更好”，而是“谁需要被谁看到”。系统变量对所有用户生效，比如你装了JDK供团队共用、或者服务器上跑Tomcat，就得配系统变量；用户变量只影响当前登录账户，适合个人开发、多版本JDK隔离、或不想动管理员权限的场景。关键点是：两者同名时，用户变量会覆盖系统变量——这既是灵活性来源，也是冲突根源。
javac找不到时大概率是PATH没继承JAVA_HOME
很多人配了JAVA_HOME，却只往用户PATH里加了%JAVA_HOME%\bin，结果命令行能java -version，但javac -version报“不是内部或外部命令”。原因很直接：Windows命令行启动时，先读取系统PATH，再拼接用户PATH，但%JAVA_HOME%在用户PATH里展开时，如果JAVA_HOME本身设在系统变量里，用户PATH里的%JAVA_HOME%\bin就无法正确解析——它只认自己作用域内的JAVA_HOME。
- 解决办法：把
JAVA_HOME也配在用户变量里（哪怕值和系统变量一样） - 或者统一配在系统变量，并确保PATH里引用的是绝对路径，比如
C:\Program Files\Java\jdk-25\bin - 验证方式：在新打开的cmd里分别执行
echo %JAVA_HOME%和where javac，看输出是否匹配
IDE识别不到JDK常因变量未被图形界面继承
IntelliJ IDEA、Eclipse这些IDE是通过图形界面启动的，它们不读你终端里用setx配的用户变量，而是依赖系统级环境或登录会话初始化时加载的配置。如果你只在用户变量里配了JAVA_HOME，又用开始菜单启动IDE，它大概率看不到。
- 稳妥做法：把
JAVA_HOME和PATH都设在系统变量里（需管理员权限） - 替代方案：用命令行启动IDE，例如
idea.bat，这样它能继承当前shell的环境 - 特别注意：
setx写入后必须新开命令行，已打开的窗口不会刷新变量值
多版本JDK共存时别混用两类变量
想同时装JDK 17和JDK 25，靠切换JAVA_HOME来控制，默认情况下改一个地方就得全局生效。这时候硬把两个版本都塞进系统变量，只会互相覆盖；全放用户变量，又可能被IDE忽略。
- 推荐组合：系统变量里只配通用工具链（如Maven的
M2_HOME），JDK相关变量全放用户变量 - 配合脚本切换：写个
use-jdk17.bat，里面用set JAVA_HOME=...临时覆盖，再启动IDE或构建命令 - 真正要长期稳定运行的服务（如Jenkins agent、Windows服务），必须用系统变量，否则服务启动时根本拿不到值
最常被忽略的一点：环境变量的“作用域”不是靠你主观意愿决定的，而是由进程启动方式和操作系统加载顺序严格控制的。配完不生效，八成不是路径写错了，而是变量没落到该进程的继承链里。
