Python中文乱码本质是编码与解码不匹配，核心解决法是读写文件时显式指定正确encoding参数；常见情形包括UTF-8带BOM需用'utf-8-sig'、GBK文件应选'gbk'、不确定时可用chardet探测或按'utf-8-sig','utf-8','gbk','latin-1'顺序尝试。
乱码不是文件“坏了”，而是 Python 用错了钥匙去开锁。绝大多数情况，open() 没写 encoding 参数，或者写了但和文件真实编码不匹配——直接指定正确编码就能解决，不用绕弯。
为什么加 encoding='utf-8' 还是乱码
常见原因不是 UTF-8 错了，而是文件实际带 BOM 或根本就不是 UTF-8：
-
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0：基本是文件为 UTF-8 with BOM，但用了encoding='utf-8'（它不自动跳过 BOM）；换成encoding='utf-8-sig'即可 - 开头出现
\ufeff字符：同上，BOM 被当作文本内容读进来了 - 报错含
byte 0x81或0xa3：大概率是 GBK/GB2312 文件，该用encoding='gbk' - 纯英文内容能读、中文一出现就崩：说明编码选对了但文件本身混了非法字节（比如剪贴时带入了控制字符），不是编码问题，是数据质量问题
不确定编码时怎么安全试出来
别靠猜，用最小代价验证。优先级建议：看来源 → 查 BOM → 用 chardet 快速探测 → 尝试常见编码列表
- 先检查是否有 BOM：用十六进制编辑器或命令行
xxd -l 4 file.txt，看到ef bb bf就是 UTF-8 with BOM -
chardet只读前 10KB 足够：import chardet; chardet.detect(open('file.txt', 'rb').read(10000))['encoding']；注意它对短文本或全 ASCII 文件可能返回ascii，不可靠 - 稳妥的 fallback 列表（按顺序尝试）：
['utf-8-sig', 'utf-8', 'gbk', 'gb18030', 'latin-1']；其中latin-1几乎总能解码（不报错），但中文会变乱码，仅用于“先读出来看看内容是否合理”
encoding='utf-8-sig' 和 'utf-8' 的区别
关键在 BOM 处理逻辑，不是“更高级”的 UTF-8：
立即学习“Python免费学习笔记（深入）”；
-
utf-8-sig：Python 自动识别并跳过开头的0xef 0xbb 0xbf，解码后字符串不带\ufeff；对无 BOM 的 UTF-8 文件完全兼容 -
utf-8：严格按 UTF-8 规则解码，遇到 BOM 就把它当普通字符塞进字符串开头，后续做.strip()或正则替换都可能误伤合法内容 - Windows 记事本另存为“UTF-8”默认带 BOM；VS Code / PyCharm 默认保存为 UTF-8 without BOM；所以只要文件来源不确定，优先用
utf-8-sig
写入文件时也必须显式指定 encoding
只管读不管写，等于给下一个人挖坑：
- 写入中文，必须写
open(..., 'w', encoding='utf-8')；不写参数，Windows 下默认用cp936（GBK），Linux/macOS 可能是utf-8，结果不可控 - 如果下游系统明确要求 GBK（如某些老旧 Windows 工具），才用
encoding='gbk'；但建议写完立刻用iconv -f gbk -t utf-8转成 UTF-8 存档 - 避免用
errors='ignore'或'replace'掩盖问题：它们会让乱码“看起来正常”，但原始信息已丢失，调试时反而更难定位
BOM 和编码探测只是表象，真正容易被忽略的是“一致性”——编辑器保存用什么编码、代码里 open() 写什么编码、终端显示用什么编码，三者差一个环节，乱码就会冒头。处理时别只盯一个点，顺手检查 VS Code 右下角编码显示、PyCharm 的 File Encodings 设置、以及 chcp 输出（Windows 命令行），比反复改 encoding 参数更省时间。
