三种典型乱码现场
现场一：脚本在记事本里跑得好好的，用 Set-Content 存过一遍再运行就乱码；现场二：管道里接原生 exe 的输出变乱码，直接在 cmd 里跑又正常；现场三：包含中文字符串的脚本执行后报"字符串缺少终止符"。三类问题看着像玄学，其实各有一个明确的根因：写文件的工具默认编码、控制台代码页、以及 BOM 的有无。
根因一：Set-Content 的默认编码不是 UTF-8
Windows PowerShell 5.1 的 Set-Content/Out-File 默认按系统 ANSI 代码页（中文系统是 GBK）写出，而 -Encoding utf8 给的又是带 BOM 的 UTF-8。文件按 GBK 写、被 Node 或 Python 工具按 UTF-8 读，自然乱码。解法：5.1 里显式加 -Encoding utf8；需要无 BOM 的 UTF-8 就升级到 PowerShell 7（默认无 BOM），或者用 [IO.File]::WriteAllText 配合 UTF8Encoding($false) 直接写字节。
根因二：控制台代码页与工具输出不一致
原生程序的输出进入 PowerShell 管道前，要经过 [Console]::OutputEncoding 解码。git、npm 这类工具默认输出 UTF-8，而 5.1 的 OutputEncoding 跟随系统 OEM 代码页（936），UTF-8 字节按 GBK 解码就是乱码。处理：在 $PROFILE 里设置 [Console]::OutputEncoding = [Text.Encoding]::UTF8；用 Windows Terminal 再配 chcp 65001。PowerShell 7 默认值已是 UTF8，升级最省事。
根因三：BOM 是双刃剑
5.1 靠 BOM 识别 UTF-8 脚本：无 BOM 的 .ps1 会被按 ANSI 读，中文字符串第一个字就截断，上面"字符串缺少终止符"多半是这个。可同一份文件被 Node、git diff、Linux shell 读时，BOM 又变成隐藏的 \\ufeff——JSON.parse 直接失败。实用规则：.ps1 保留 BOM 迁就 5.1；JSON/CSV 这类数据文件统一无 BOM UTF-8；代码读这类文件先防御性剥 BOM（replace(/^\\uFEFF/, '')）。
收个尾
决策树其实很短：磁盘上乱码 → 检查写入工具的编码参数；只在控制台乱码 → 查 OutputEncoding 和 chcp；文件内容正常但 JSON.parse 或字符串比较总差一个隐形首字符 → BOM。找到根因修配置，比到处"换个编辑器另存一下"快得多。
