unicodedecodeerror主因是系统默认编码（如windows的cp936）与文件实际编码（如utf-8）不匹配，根本解法是显式指定encoding参数，如encoding='utf-8'或encoding='gbk'，而非依赖自动探测或容错模式。
open() 报 UnicodeDecodeError 是因为系统默认编码不匹配
Windows 上 Python 默认用 locale.getpreferredencoding()（通常是 'cp936'），而文件实际是 UTF-8 编码，读取时就会在非 ASCII 字符处崩掉。Linux/macOS 虽多用 UTF-8，但遇到 BOM、混合编码或终端 locale 异常时照样报错。
根本解法不是“试试看”，而是**显式声明 encoding**——这不是可选项，是必须项。
- 永远优先写
open(..., encoding='utf-8')，哪怕你“确定”是英文文本 - 如果真要读 GBK 编码的文件（比如老 Windows 记事本保存的），明确写
encoding='gbk'或encoding='gb18030' - 用
errors='ignore'或errors='replace'只能掩盖问题，不能解决乱码源头
用 chardet 自动探测编码风险很高
很多人一遇到报错就去装 chardet，跑 chardet.detect() 猜编码。但实际中：
- 小文件（
- UTF-8 和 GBK 对 ASCII 字节完全一致，
chardet很可能误判为'ascii' - 探测完再 open 会多一次 IO，且无法保证和写入时编码一致（比如别人用 Notepad++ 选了 UTF-8 with BOM，你却按无 BOM 解码）
更稳妥的做法是：查来源——配置文件？爬虫响应？用户上传？日志系统？根据上下文预设编码，而不是靠猜。
encoding='utf-8-sig' 专门对付带 BOM 的 UTF-8 文件
Windows 记事本保存 UTF-8 时默认加 BOM（\ufeff），直接用 encoding='utf-8' 读出来，第一行开头会多一个不可见字符，导致 JSON 解析失败、字符串比较异常、正则匹配偏移等隐性 bug。
- 读取时用
encoding='utf-8-sig'，Python 会自动剥离 BOM，返回干净字符串 - 写入时若需兼容记事本，用
encoding='utf-8-sig'；若给程序间交互用（如 API、数据库），坚持用纯'utf-8'更安全 - 注意：
'utf-8-sig'只影响读写行为，不是一种独立编码格式
命令行运行脚本时，sys.stdout.encoding 可能拖后腿
即使 open() 没报错，print 中文仍显示 或直接崩溃，常见于 Windows CMD/PowerShell 启动 Python 脚本：
- 检查
sys.stdout.encoding是否等于sys.getdefaultencoding()—— 常见不一致 - 临时修复：启动时加
python -X utf8 script.py（3.7+），强制 stdout 使用 UTF-8 - 长期方案：改用 VS Code 终端、Windows Terminal，或在脚本开头加
import io; import sys; sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')
别以为 open 不报错就万事大吉，输出通道的编码陷阱更难定位。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
