PowerShell 5.1 中文脚本的四类静默失败：编码、路径、行尾、退出码

开头：一次「文件明明存在却报找不到」的事故

前阵子写了一批 Windows 上的自动化脚本，统一放在一个中文目录下。脚本在本机手跑完全正常，一旦塞进计划任务就用不了，报错五花八门：有的是 未能找到路径，有的是 SyntaxError，还有的直接静默退出、退出码 0。

排查了半天才确认根因很单一：PowerShell 5.1 读取无 BOM 的 UTF-8 脚本时，会按系统 ANSI 代码页（简体中文环境即 GBK）解码。脚本里本身含有中文，于是字节被错误切分，字符串变成了乱码，正则和路径自然全崩。更麻烦的是这类错误经常不致命——脚本"跑完了"，只是结果全错，比直接崩掉更难发现。

这篇把踩过的坑和现行的规避规则整理成一份可执行的清单。

一、编码：三行规则定死

1. 脚本内容只用 ASCII。路径、注释、输出文案全部走英文，中文一律从数据文件读入（用 -Encoding UTF8 显式指定）。
2. 必须写中文时，存成带 BOM 的 UTF-8。BOM 是 PowerShell 5.1 唯一可靠的编码判据；不带 BOM 就退化成 GBK 猜测。
3. 调用外部工具时别指望管道编码一致。python、git、ffmpeg 的输出编码各不相同，用 $OutputEncoding 与 [Console]::OutputEncoding 统一到 UTF-8，并在解析前做一次 -replace 清洗。

一条实用自检：脚本开头打印 [System.Text.Encoding]::Default.WebName，能立刻看出当前是 GBK 还是 UTF-8。

二、路径：中文目录是重灾区

• 用 Join-Path 拼路径，不要手写反斜杠拼接，避免 \ 被当成转义。
• 传给外部程序时用 --%（停止解析）或数组参数形式，避免空格与中文被二次切词。
• 计划任务的"起始于"字段必须显式填写，否则工作目录是 C:\Windows\System32，相对路径全部失效。

三、定时任务：三个必查项

批处理还有一条独立的坑：.bat 必须是 CRLF 行尾。用 LF 保存的批处理会被 cmd.exe 错误解析，典型症状是 goto 跳错、if 块被截断，甚至整段被当作注释吞掉，同样以退出码 0 结束。

四、让失败可见

自动化最怕"看起来成功了"。我的做法是：

1. 每个关键步骤后写一行 STEP OK: <名称> 到日志文件，最后统一检查条数；
2. 所有外部命令检查 $LASTEXITCODE，非 0 立即 throw；
3. 脚本最外层 try/catch，catch 里把 $_.Exception.Message 与 $_.InvocationInfo.PositionMessage 落盘——后者会直接指出出错行号，比任何猜测都快。

结语

这类问题的共同特征是：环境差异不被显式表达，就一定会以"随机故障"的形式出现。把编码、工作目录、行尾、退出码四件事在脚本里写死并自检，故障率会降到接近零。写脚本的时间省不下来，但排查玄学故障的时间可以。