脚本在家里那台 Linux 机器上跑得好好的，搬到 Windows 上，只要一打印带 emoji 的状态行，或者输出几句中文，就直接抛异常退出。更气人的是它退出的时机——往往正好在「已经改了一半数据、还没写回文件」的中间状态，留下一堆需要手工收拾的残局。
现象
抛出的异常长这样：
UnicodeEncodeError: 'gbk' codec can't encode character '⚠' in position 0:
illegal multibyte sequence
触发它的字符五花八门：⚠️、✅、真减号 −（不是键盘上那个 -）、©、以及各种 emoji。如果输出的是纯中文，通常不报错，只是显示成乱码。
注意异常类型是 EncodeError，不是 DecodeError——问题出在「往外写」的方向，而不是「往里读」。
根因
Windows 上 Python 的 sys.stdout 会按控制台的代码页决定用什么编码输出。在简体中文 Windows 上，这个代码页是 GBK（CP936）。
关键点在于：GBK 能表示的字符集是有限的。 汉字基本都在里面，但 emoji、⚠️、部分数学符号、各种装饰性字符都不在。当 Python 要把一个 GBK 表示不了的字符写进 stdout 时，它不会悄悄跳过或替换，而是直接抛 UnicodeEncodeError。
这和「乱码」的区别在于：能编码但编错了，是乱码；编不了，就是异常。emoji 属于编不了的那一类，所以是硬崩。
为什么 Linux 上没事？因为 Linux 环境通常是 UTF-8，UTF-8 几乎能表示所有 Unicode 字符，不存在「编不了」的情况。
还有一个放大伤害的细节：因为异常是在输出的一瞬间抛出的，如果脚本的流程是「读入 → 处理 → 打印进度 → 写回」，那崩溃点很可能落在「处理完了、还没写回」之间，于是留下不一致的中间状态。
解决
有三层办法，从轻到重，建议根据场景选。
第一层：运行前设环境变量。
PYTHONIOENCODING=utf-8 python script.py
PYTHONIOENCODING 会覆盖 Python 对标准输入输出的默认编码，让 stdout/stderr 都用 UTF-8。这是最不侵入代码的做法，适合「只是跑一下、不想改脚本」的场合。
第二层：在脚本开头强制重配置。
import sys
try:
sys.stdout.reconfigure(encoding='utf-8', errors='replace')
sys.stderr.reconfigure(encoding='utf-8', errors='replace')
except AttributeError:
pass # Python 3.6 及更早没有 reconfigure
errors='replace' 是关键——它让「编不出来的字符」退化成 ? 之类，而不是抛异常。reconfigure 是 Python 3.7+ 才有的方法，所以旧版本用 try/except 兜一层，或者退回用 PYTHONIOENCODING。
第三层：从源头避免。
把输出里的装饰性字符去掉。进度标记用 [OK]、[WARN] 这种纯 ASCII，别用 emoji。这不是「规避 bug」，而是承认控制台是个比文件更受限的输出目标——终端要兼容各种字体、各种代码页，用非 ASCII 装饰本来就是在赌运气。
最稳妥的是双管齐下：既强制 UTF-8，也不在输出里用非 ASCII 装饰字符。
延伸与预防
- 记住异常的方向：
EncodeError是「往外写」时编不了，DecodeError是「往里读」时解不了。两者排查思路完全不同，先分清再动手。 - 更通用的原则：打印不是原子操作。 一旦脚本涉及「读—改—写」，就要意识到任何一次打印都可能成为崩溃点。养成在真正写回文件之前不做花哨输出的习惯，或者用「先写临时文件再原子替换」的方式来保护数据。
- 这条坑值得在脚本第一行就处理掉。控制台编码问题和你的业务逻辑无关，它只会在最不巧的时刻冒出来，把它当成脚本骨架的一部分固定下来，比事后 Debug 划算得多。