在 Windows 11 里用 PowerShell 处理文件时，文路中文路径报错是径报很常见的一类问题。典型表现是错注：明明资源管理器里能看到文件夹，cd 却提示“找不到路径”；或者脚本里写死了中文目录，文路运行时提示“系统找不到指定的径报文件”；还有一种是文件确实被处理了，但输出里的错注中文变成乱码，让人误以为路径错了。文路这类问题往往不是径报单一原因，而是错注编码、引号、文路转义、径报权限和命令本身的错注行为叠加在一起。下面按排查顺序讲清楚该注意什么。文路

先分清是径报“路径不存在”还是“编码没对上”

第一步不要急着改脚本，先做最小验证。错注在 PowerShell 里依次执行 Get-Location 看当前目录，再用 Test-Path "你的中文路径" 判断路径是否被正确识别。如果 Test-Path 返回 False，但资源管理器里确实存在，问题多半出在字符编码或不可见字符上，而不是路径真的不存在。

常见诱因有三个：一是从网页、聊天工具复制路径时带入了全角空格、零宽字符或弯引号；二是路径里混用了中文全角括号、顿号等符号，与磁盘上的实际名称不一致；三是脚本文件本身以非 UTF-8 编码保存，PowerShell 读取时把中文解析成了别的字符。可以先在记事本里把路径重新手打一遍做对照，排除复制污染。

引号、空格与转义：最容易踩的三个坑

中文路径通常伴随空格或特殊符号，PowerShell 会把未加引号的空格当作参数分隔符。因此含空格的中文路径必须用双引号包裹，例如 Set-Location "D:\工作资料\2024 项目"。单引号也能用，但单引号内不做变量展开，需要拼接变量时要用双引号。

第二个坑是路径里的方括号。[ 和 ] 在 PowerShell 的部分命令中被视为通配符字符，路径含方括号时可能匹配失败。稳妥做法是用 -LiteralPath 参数替代 -Path，多数文件类命令都支持这个参数。第三个坑是反斜杠结尾，某些命令对末尾的 \ 敏感，拼接路径时建议用 Join-Path 而不是手工加斜杠。

如果路径来自变量，先 Write-Output $p 打印出来看清实际内容，再传给命令。很多“中文路径报错”其实是变量里多了换行符或前后空格，用 .Trim() 处理一下即可。

编码设置与控制台显示，别把乱码当报错

Windows 11 的 PowerShell 7 默认使用 UTF-8，而系统自带的 Windows PowerShell 5.1 默认代码页与系统区域设置相关，中文环境下通常是 GBK 系列。两者混用时，脚本里的中文可能显示为乱码。可以在当前会话临时查看编码：[Console]::OutputEncoding，需要时用 [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 调整，但这只影响当前会话，新开窗口会恢复。

更根本的做法是把脚本文件统一保存为带 BOM 的 UTF-8，或在脚本开头显式声明编码偏好，避免不同机器上行为不一致。读取和写入文本文件时，注意 Get-Content 与 Set-Content 的 -Encoding 参数，读写两端编码不一致同样会造成中文内容损坏。判断标准很简单：路径能通过 Test-Path，但输出文字是乱码，那就是显示或编码问题，不是路径问题。

权限、长路径与执行策略，失败时的排查顺序

排除了编码和引号之后，再按下面顺序查：其一，权限。访问系统目录或他人共享目录时，即使路径正确也会提示拒绝访问，可先用 Get-Acl 查看当前账户是否有读权限，必要时以管理员身份重开终端再试。其二，长路径。深层嵌套的中文目录容易逼近传统路径长度限制，可尝试缩短层级，或在系统设置中确认已启用长路径支持，具体入口以本机系统版本界面为准。其三，执行策略。如果报错发生在运行 .ps1 脚本时，先看 Get-ExecutionPolicy 的返回值，脚本被拦截与路径无关，不要混为一谈。

还有一个容易忽略的点：部分命令的当前工作目录与 PowerShell 的当前位置并不一致，尤其是调用外部程序时。遇到“文件明明在却找不到”，可以在命令前显式切换到目标目录，或直接传绝对路径，减少相对路径带来的歧义。涉及系统级配置或批量改动的操作，建议先在测试目录用少量文件验证，确认无误再扩大范围。

小结一下可执行的做法：先用 Test-Path 判定路径是否被识别，含空格和方括号的路径一律加双引号并优先用 -LiteralPath，打印变量确认没有隐藏字符，统一脚本与终端的编码，最后再查权限、长路径和执行策略。把这四步按顺序走一遍，绝大多数 Windows 11 PowerShell 中文路径报错都能定位到具体原因，而不是靠反复重装或改系统设置碰运气。