来源：2026-06-28 修复 PowerShell UTF-8 乱码会话、2026-05-24 PowerShell 编码问题会话
这篇文章由本地 Codex 历史会话整理而来，保留可复用的工程经验，省略私有路径、账号、临时日志和不适合公开发布的细节。
问题不是“显示难看”，而是数据在进入程序前已经被改写
这次会话的起点很典型：PowerShell 输出把 UTF-8 中文显示成乱码，脚本第一次运行时还会被中文路径、中文列名和管道编码影响。表面上看像是 Python、pandas 或控制台显示的问题，但真正的不变量是：同一段中文文本从文件、Shell、管道进入 Python 后，字节序列不能被中途替换。
一旦 Windows PowerShell 5.1 用本地代码页把脚本或管道内容送给 python -，中文在 Python 读取前就可能已经变成问号。此时再在 Python 内部设置 encoding="utf-8"，只能修复输出端，无法恢复已经损坏的输入。
修复路径
第一步是把问题拆成输入、状态、转换、输出四段：文件本身是否是 UTF-8；PowerShell 子进程的 $OutputEncoding 是什么；Console 输入输出编码是什么；活动代码页是否为 65001；最后再实际输出一段中文做验证。
第二步是把易碎点从业务脚本里移出去。对于需要读取中文列名的脚本，不再依赖源码里的中文字面量，而是使用 ASCII 源码和 Unicode 转义来定位列名，再标准化成 issue/date/num1... 这类内部字段。这样业务逻辑面对的是稳定的英文键，编码风险被限制在 I/O 层。
第三步是把启动环境固化到 PowerShell profile：$OutputEncoding = utf-8、Console 输入输出均设为 UTF-8，并切换 chcp 65001。验证不是看“看起来没乱码”，而是启动新的子进程确认 OutputEncoding=utf-8、ConsoleOutput=utf-8、ConsoleInput=utf-8 和中文样例都正常。
可复用经验
不要在业务脚本里散落编码补丁。编码是一条链路，只要其中一段提前损坏，后面全部无效。
把外部世界的复杂字段统一映射为内部稳定字段，是比“到处 try encoding”更可维护的做法。
Windows 上处理中文、Excel 和管道时，要把 Shell 配置、文件编码、程序读取方式一起验证，单测只覆盖 Python 代码是不够的。