优先配置用户变量，因为无需管理员权限、不影响其他账户和域策略，且PATH中%GRADLE_HOME%\bin可覆盖系统PATH；GRADLE_USER_HOME也必须设为用户变量并避开系统盘根目录以防权限问题。
优先配置用户变量，除非你明确需要让所有 Windows 用户共享同一套 Gradle 环境。
为什么用户变量更安全、更可控
在 Windows 上，GRADLE_HOME 和 PATH 中的 %GRADLE_HOME%\bin 都建议设为「用户变量」，原因很实际：
- 不需要管理员权限就能修改，避免每次配环境都要右键“以管理员身份运行”
- 不会影响其他账户（比如你给同事或家人用的账号），也不会干扰公司域策略下发的系统级设置
- 当系统变量和用户变量同时存在
GRADLE_HOME时，Gradle 自身不读取它 —— 它只关心PATH能否找到gradle.bat；但用户变量的PATH会追加到系统PATH后面，天然具备覆盖能力 - 如果你后续想切换 Gradle 版本（比如临时用 7.6 跑老项目），只需改用户变量，不影响系统变量里可能存在的其他工具链
系统变量什么时候必须用
只有两种情况值得动系统变量：
- 你在一台开发机上给多个非管理员账号（如 CI 服务账户、Jenkins Agent）提供统一构建环境，且这些账户无法登录桌面、不继承用户环境
- 你用的是企业级镜像/安全加固策略，要求所有 Java 工具链（JDK、Maven、Gradle）必须通过系统变量集中管控，且有配套的组策略刷新机制
注意：即使用了系统变量，也仍要确保 GRADLE_USER_HOME 这类影响缓存位置的变量设为用户变量——否则多个用户共用一个 .gradle 目录，容易引发权限冲突或缓存污染。
PATH 中 %GRADLE_HOME%\bin 的写法陷阱
很多人复制粘贴时直接写死路径（如 D:\tools\gradle\gradle-8.5\bin），这看似省事，实则埋雷：
- 升级 Gradle 后要手动改两次：
GRADLE_HOME和PATH，漏改一个就失效 - 如果
GRADLE_HOME是用户变量，而PATH里写的是绝对路径，那GRADLE_HOME就完全没意义了 - Windows 命令行对路径中空格和括号极敏感，用
%GRADLE_HOME%可自动包裹引号逻辑，比手写C:\Program Files\...更健壮
正确做法：在用户变量 PATH 里新增一行 %GRADLE_HOME%\bin，并确保 GRADLE_HOME 本身是用户变量、值不含末尾反斜杠（如 D:\tools\gradle\gradle-8.5，不是 D:\tools\gradle\gradle-8.5\）。
真正容易被忽略的点是：GRADLE_USER_HOME 必须设为用户变量，且路径不能指向系统盘根目录（如 C:\.gradle）——NTFS 权限和 UAC 会悄悄拦截写入，导致 daemon 启动失败或缓存静默损坏。推荐放在 %USERPROFILE%\gradle 或另一块盘的独立目录下。
