setx仅字符串拼接不展开变量，[environment]::setenvironmentvariable支持作用域控制与%var%语法展开；前者易致java_home未解析，后者需管理员权限写machine级变量且须新开窗口验证。
PowerShell里setx和[Environment]::SetEnvironmentVariable的区别
两者都能写入注册表实现永久生效，但行为差异很大：setx是外部命令，只处理字符串拼接，不解析变量引用；[Environment]::SetEnvironmentVariable是.NET原生方法，支持"User"/"Machine"作用域控制，且能正确展开%JAVA_HOME%这类语法（只要注册表里已存在该变量）。
常见错误现象：用setx PATH "%PATH%;%JAVA_HOME%\bin"后java仍报“不是内部或外部命令”——因为setx把%JAVA_HOME%当纯文本写进注册表，没做变量展开。
-
setx JAVA_HOME "D:\jdk\jdk-21.0.3" /M→ 安全，值是静态路径 -
setx PATH "%PATH%;%JAVA_HOME%\bin" /M→ 危险，%JAVA_HOME%不会被替换 - 正确做法：先设
JAVA_HOME，再用[Environment]::GetEnvironmentVariable("JAVA_HOME", "Machine")取值拼PATH
必须以管理员身份运行PowerShell的场景
写系统级变量（"Machine"）时权限不足会静默失败，无报错但注册表没更新。验证方式：执行后立即查注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment下是否存在对应键值。
用户级变量（"User"）不需要管理员权限，但多数开发工具（如Maven、IDEA）默认读系统变量，仅设用户级可能导致工具识别不到JDK。
- 设
JAVA_HOME到系统变量 → 必须管理员权限 - 追加
%JAVA_HOME%\bin到系统Path→ 必须管理员权限 - 临时测试用
$env:JAVA_HOME = "D:\jdk\jdk-21.0.3"→ 无需权限，但关窗口即失效
PATH追加时顺序和分隔符的坑
Windows按PATH中目录从左到右查找可执行文件，旧版本JDK路径如果排在前面，java -version可能返回错误版本。分隔符必须是英文分号;，不能用逗号或冒号。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
直接拼接$env:PATH有风险：当前会话$env:PATH可能包含用户级路径，而系统级Path注册表值才是全局生效的源。
- 安全做法：用
[Environment]::GetEnvironmentVariable("Path", "Machine")读原始系统PATH - 追加新路径时，显式加
;前缀："D:\jdk\jdk-21.0.3\bin;" + $originalPath - 避免用
$env:PATH += ";D:\..."，这只会改当前会话，不写注册表
配置后为什么java -version还是不生效
最常被忽略的是：PowerShell窗口不会自动继承新写的注册表环境变量。即使脚本执行成功，当前窗口的$env:PATH仍是旧值。
验证必须开全新窗口，不能靠RefreshEnv或重启explorer——这些操作对系统级变量无效。
- 新开PowerShell窗口后，先运行
echo $env:JAVA_HOME确认变量存在 - 再运行
echo $env:Path | Select-String "jdk"确认bin目录已加入 -
where.exe java比java -version更可靠，它直接查PATH所有目录，不依赖缓存
路径含空格（如C:\Program Files\）本身不影响[Environment]::SetEnvironmentVariable，但后续用where或exec.Command调用时可能因引号缺失出错——建议安装JDK时就选无空格路径。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
