必须以管理员身份运行powershell并指定"machine"作用域才能永久修改系统path；仅用$env:path+=...或setx命令无效，需查注册表或新开终端验证，且追加时应读取原值再拼接以防覆盖。
PowerShell里用 [Environment]::SetEnvironmentVariable 修改系统级 PATH
直接改系统环境变量必须提权，而且得指定作用域为 Machine，否则只影响当前会话或用户。不加作用域参数默认是 User，很多人配完发现 cmd 或新 PowerShell 窗口里 java -version 还是报错，就是因为没写对作用域。
实操建议：
- 以管理员身份运行 PowerShell（右键 → “以管理员身份运行”）
- 先读出现有值，避免覆盖：
[Environment]::GetEnvironmentVariable("PATH", "Machine") - 追加 Java 的
bin目录（注意末尾不加分号）：[Environment]::SetEnvironmentVariable("PATH", $env:PATH + ";C:\Program Files\Java\jdk-21\bin", "Machine") - 改完后必须重启所有已打开的终端窗口，环境变量不会热更新
为什么不用 $env:PATH += "..." 就够了？
因为那只是临时修改当前 PowerShell 进程的环境变量，关掉窗口就失效，连新起一个 PowerShell 都不继承。它不写注册表，也不触达系统级配置，适合调试或单次脚本运行，但不能当“配置 Java”的最终方案。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 在当前窗口执行
$env:PATH += ";C:\jdk\bin"后java能用了，但新开窗口又不行 - 误以为
setx PATH "%PATH%;C:\jdk\bin"（CMD 命令）在 PowerShell 里能直接用 —— 实际上setx在 PowerShell 中行为不稳定，且不支持长路径和 Unicode，容易截断
检查 Java 路径是否生效的可靠方式
别只信 echo $env:PATH，它只显示当前会话的值。要验证系统级配置是否落盘，得绕过缓存去查注册表或用新进程验证。
实操建议：
- 查注册表确认写入：
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name PATH - 开一个全新 PowerShell（非从旧窗口启动），直接运行
java -version - 如果报
The term 'java' is not recognized，大概率是路径拼错、权限不足，或 JDK 安装目录下真没java.exe（比如只下了 JRE 或解压包没进bin）
PowerShell 脚本自动检测 JDK 并追加 PATH 的安全写法
手动填路径容易出错，尤其当 JDK 装在非标位置（如 C:\dev\jdk-17.0.2）或版本升级后。用脚本能规避硬编码，但要注意路径存在性判断和权限校验。
简短示例（可直接复制运行，需管理员权限）：
if (Test-Path "C:\Program Files\Java\jdk-*\bin\java.exe") {
$jdkBin = Resolve-Path "C:\Program Files\Java\jdk-*\bin" | Select-Object -First 1
$newPath = [Environment]::GetEnvironmentVariable("PATH", "Machine") + ";" + $jdkBin.Path
[Environment]::SetEnvironmentVariable("PATH", $newPath, "Machine")
}
关键点：
- 用
Test-Path和通配符匹配，避免依赖固定版本号 -
Resolve-Path确保拿到真实路径，防止符号链接或空格导致问题 - 不直接覆盖
PATH，而是读原值再拼接，防止意外清空系统路径
真正麻烦的是多 JDK 共存时路径顺序——Windows 按 PATH 从左到右找第一个 java.exe，顺序错了就调用错版本，这个得自己盯住。
