按道理不是用户变量在系统变量前面的吗？现在在我电脑，不管是 git bash ，powershell 还是 cmd ，输的 path 都是系统变量在用户变量前面
 | 1 Melting 1 天前 我测试自己的电脑，看起来应该是 path 是系统>用户，其他的是用户>系统 |
 | 2 xtreme1 1 天前 Path=%Path%(System);%Path%(User) |
 | 4 jifengg 1 天前 一直没注意这个事情，看了我的，是系统在前面。所以你的没错。 |
 | 5 body007 1 天前 可以用 clink 或者 cmderr 在脚本中将你想要的环境变量放前面，类似下面这种，但只能生效到打开的 cmd 额。  |
 | 6 skiy 22 小时 28 分钟前 直接 echo $env:PATH 对比一下，看看是系统里配的在前还是在后就知道了。 |
 | 7 geelaw 22 小时 13 分钟前  6 除了 PATH 以外都是用户先于系统，PATH 由 系统 > 用户 的顺序合成我不知道是什么时候开始的，但从 Vista 以来这个设计可以缓解一些 UAC 提权攻击。 假设 PATH 是 用户 > 系统 的顺序，那么在 Vista 上，管理员用户运行的非提权程序当然可以修改用户的 PATH ，这会导致重新登录后提权程序的 PATH 先搜索非提权程序指定的目录，是一种提权攻击的渠道。UAC 禁止提的时候继承环境变量也是出于这个考虑。 反之，如果是 系统 > 用户，那么提权程序的 PATH 先搜索的目录只有提权时才能修改，不存在越权的问题。 如果提权程序搜索 PATH 的时候本来就无法从系统级 PATH 找到，那么这是提权程序的设计问题，无论哪种顺序都不安全，因此对决定 系统/用户 级别 PATH 谁优先不作贡献。 |
 | 8 yulon 20 小时 18 分钟前 而且系统是即时生效，用户要重启 GUI shell (explorer.exe)，导致我从来不用用户 |
| 9 geelaw 20 小时 13 分钟前 1 @yulon #8 explorer.exe 是会对 WM_SETTINGCHANGE "Environment" 作出反应的，如果你需要重启 shell 才有效，说明改变环境变量的进程忘记广播此消息。 |
 | 10 jim9606 18 小时 42 分钟前 1 如果系统 PATH 优于用户 PATH ，可能是为了避免一些重要系统程序(cmd,rundll,regsvr32,explorer)被无需特权即可改写的用户 PATH 截胡用以实现恶意行为（邪恶女仆攻击），系统 PATH 排头的通常是需要特权读写的目录，无特权的话写不进去。这算是一种安全策略。 类似的还有 DLL 搜索顺序，特定几个 KnownDLLs(kernel32 、user32 、shell32 、WS2_32 等)优先在系统目录搜索。 |
 | 11 gogogo2000 8 小时 32 分钟前 @jim9606 类似的还有 DLL 搜索顺序，特定几个 KnownDLLs(kernel32 、user32 、shell32 、WS2_32 等)优先在系统目录搜索 KnownDLLs 的信息是写在注册表中的，根本就不会搜索非系统文件夹，无论你怎么修改 path 都没有用 |
Select Language