PowerShell中$env:USERPROFILE与资源管理器%USERPROFILE路径不一致导致目录定位报错

你碰到的跨场景路径返回差异是Windows系统设计层面的预期行为，不属于系统故障，核心原因是两个场景的路径解析逻辑从底层就是解耦的：

路径不一致的核心成因 #

• 文件资源管理器解析%USERPROFILE%/Downloads时，并不会直接对环境变量值做字符串硬拼接。它会优先读取系统注册表里记录的「已知文件夹（Known Folder）」配置，直接定位你实际自定义的Downloads存储位置，所以能正确跳转到你迁移后的D盘路径。
• 你在PowerShell脚本里写的$downloadDirectory = "$env:USERPROFILE\Downloads"是纯粹的字符串拼接逻辑，路径有效性完全依赖两个硬编码前提：
  • 当前PowerShell进程加载的$env:USERPROFILE值和系统实际用户目录一致
  • Downloads文件夹必然直接存放在用户目录下，没有被用户迁移到其他位置
• 你当前的报错恰好同时触发了两个前提失效：
  1. 你此前已经把Downloads文件夹从默认的C盘用户目录（C:\Users\skewb\Downloads）迁移到了D盘（D:\Users\Skewb\Downloads），C盘原位置已经不存在Downloads文件夹。
  2. 你运行脚本的PowerShell进程是在迁移Downloads之前启动的——Windows的环境变量是进程启动时就固定的快照值，不会随系统配置实时刷新，所以这个进程拿到的$env:USERPROFILE还是迁移前的旧值，拼出来的路径自然不存在。

注意：哪怕你重启PowerShell拿到了最新的USERPROFILE值，硬拼接Downloads路径的写法依然有失效风险。从Windows Vista开始，所有用户特殊文件夹（下载、文档、图片、桌面等）都支持用户自定义存储位置，系统从来不会强制要求这些文件夹必须放在用户目录下，也不会把自定义的特殊文件夹路径自动映射到USERPROFILE的拼接逻辑里。

可靠的Downloads目录定位方案 #

完全替代硬拼接的写法，实现和资源管理器完全一致的路径定位效果，适配所有自定义迁移场景：

• 通用兼容方案（支持PowerShell 5.1及所有后续版本，和资源管理器走同一套系统路径解析链路）：

  $shell = New-Object -ComObject Shell.Application
  $downloadDirectory = $shell.NameSpace('shell:Downloads').Self.Path
  

  写完可以直接用Test-Path $downloadDirectory验证路径有效性，不会出现硬拼接导致的路径不存在问题。
• 无COM依赖的注册表读取方案：

  # 读取Downloads对应的系统已知文件夹注册表配置
  $regItem = Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' -Name '{374DE290-123F-4565-9164-39C4925E467B}'
  # 展开路径中的环境变量占位符，得到完整的实际路径
  $downloadDirectory = [Environment]::ExpandEnvironmentVariables($regItem.'{374DE290-123F-4565-9164-39C4925E467B}')
  

• 快速排查技巧：如果怀疑当前PowerShell进程的环境变量值过期，直接执行$env:USERPROFILE，对比资源管理器里用户目录的实际路径即可，值不一致时重启PowerShell或者注销重登系统就能刷新快照。

内容的提问来源于stack exchange，提问作者Skewjo