根本原因是Python用UTF-8而Windows CMD默认用GBK解码，导致UnicodeEncodeError；需在脚本开头重置sys.stdout/stderr编码为UTF-8并配合chcp 65001使用。
为什么print()在Windows CMD里会报GBK编码错误
根本原因是Python内部用UTF-8处理字符串，而CMD默认用GBK（代码页936）解码输出字节流。当print()尝试把含Unicode字符（比如 、 emoji、生僻字）的字符串写入sys.stdout.buffer时，底层调用GBK编码器失败，抛出UnicodeEncodeError: 'gbk' codec can't encode character '\ue615' in position...这类错误。
这不是Python bug，也不是文件或字体问题——是终端和Python运行时之间“说不同语言”导致的协议错配。
- 错误只在CMD/PowerShell中出现，VS Code终端、IDLE、PyCharm控制台通常无此问题
-
input()读中文也可能乱码，原因相同：stdin同样受当前代码页约束 - Python 3.7+会尝试自动适配，但仅对CP65001（UTF-8）生效，而CMD默认不启用它
最稳的脚本内修复：重置sys.stdout和sys.stderr
不依赖外部环境，直接在Python脚本开头强制接管输出通道，让Python自己按UTF-8编码、再交由CMD以UTF-8解释（前提是CMD已设为65001，或你用gb18030兜底）。
推荐写法：
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
import sys
import io
if sys.platform == 'win32':
sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8', errors='replace')
sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8', errors='replace')
- 必须放在
print()、logging、input()等任何I/O操作之前 -
errors='replace'比'ignore'更安全：遇到无法编码的字符，显示而不是静默丢弃 - 若发现输出变成繁体或仍乱码，可临时换成
encoding='gb18030'（GBK超集，兼容性更强） - 不影响Linux/macOS，
sys.platform == 'win32'做了平台隔离
配合chcp 65001使用才真正闭环
光改Python端不够：CMD本身得支持UTF-8解码。否则即使Python输出了UTF-8字节，CMD仍用GBK去“猜”，结果还是方块或问号。
执行顺序很重要：
- 先在CMD中运行
chcp 65001（活动代码页变为65001） - 再运行你的Python脚本（此时
sys.stdout.encoding通常能正确识别为utf-8） - 如果跳过第一步，上面的
io.TextIOWrapper设置可能被CMD底层API忽略
注意：chcp 65001只对当前CMD窗口有效；PowerShell默认用UTF-16，但Python启动后仍可能误判sys.stdout.encoding为cp1252，所以脚本内重置仍是必要动作。
读文件时别踩open()默认编码的坑
很多报错表面是print()引发，根源却在上游——比如用open('data.txt').read()没指定encoding，Python按locale.getpreferredencoding()（通常是GBK）去读一个UTF-8文件，结果读出来就是损坏的字符串，后续print()只是“替上游背锅”。
- 显式声明编码：优先试
encoding='utf-8-sig'（兼容BOM），再试'gb18030' - 不要依赖编辑器保存格式：VS Code默认UTF-8，记事本可能存GBK，同一文件在不同机器上行为不一致
- 网络响应（如
requests.get().text）要检查r.encoding，必要时手动设r.encoding = 'utf-8'
真正容易被忽略的是：输出乱码常常是输入就错了。查print()前先print(repr(content))看字符串是否已是乱码，比盲目修输出更高效。
