Sublime Text 3中文乱码主因是解码方式与文件真实编码不匹配；应先用file -i（Linux/macOS）或Notepad++（Windows）确认真实编码，再通过Reopen with Encoding临时解码、Save with Encoding转存，配置中需设"default_encoding": "UTF-8"和"fallback_encoding": "Chinese (GBK)"并禁用detect_encoding与save_with_bom。
Sublime Text 3 中文乱码不是字体或系统语言问题，而是解码方式和文件真实编码不匹配——90% 的“乱码”根本没改错地方，只是在瞎试编码。
怎么确认文件真实编码，而不是靠猜
Sublime 右下角显示的 UTF-8 或 Western (ISO 8859-1) 只是它当前怎么读这个文件，不是文件本来就是这个编码。满屏方块时，它可能正用 UTF-8 解一个 GBK 文件。
- Linux/macOS 下直接运行：
file -i 文件名，看输出里的charset=字段（如charset=gbk） - Windows 用户用 Notepad++ 打开 → 右下角明确显示 “
GBK” 或 “UTF-8-BOM”，比 Sublime 更可信 - 别信网上说的“用 Python 脚本检测”——短文本、混合编码、BOM 干扰下，纯字节分析误判率极高
Reopen with Encoding 和 Save with Encoding 到底该点哪个
这是最常点错的两个菜单项，功能完全相反，点错一次就可能把能读的文件“转坏”。
-
Reopen with Encoding：只改当前视图怎么读文件，不写磁盘，安全。适合乱码后立刻试Chinese (GBK)、UTF-8、GB2312，看到中文就停 -
Save with Encoding：真把当前视图内容按新编码重写到磁盘，不可逆。必须在Reopen with Encoding确认显示正常后才用 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写，且不提示，原始编码信息直接丢失
用户设置里 fallback_encoding 为什么不能写 "UTF-8"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。Sublime 只认自己内置的编码标识符。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"或"Western (ISO 8859-1)" -
default_encoding才支持"UTF-8"，它管新建文件和显式保存时的默认编码 - 推荐配对使用：
"default_encoding": "UTF-8"+"fallback_encoding": "Chinese (GBK)"，兼顾新文件和旧项目乱码文件 - 顺手删掉配置里可能存在的
"detect_encoding": true——这个开关会让 Sublime 主动跳过 UTF-8 去试 GBK，反而把带 BOM 的 UTF-8 文件判成乱码
保存后其他工具报错 Non-UTF-8 code starting with '\xef'
这不是 Sublime 没设对，而是它悄悄加了 UTF-8 BOM（\xef\xbb\xbf），Python、Git、Shell 脚本都把它当非法字符。
- 检查是否生效：
xxd 文件名 | head -n1，输出不含ef bb bf才算干净 - 关掉 BOM：在用户配置里加
"save_with_bom": false，只靠"default_encoding": "UTF-8"不够 - 如果文件本身是 GBK 编码，硬设默认 UTF-8 就会出问题——Sublime 不支持自动编码探测，只能靠人工干预或规则匹配
真正麻烦的不是配置本身，而是你得先分清：这文件到底是 UTF-8 还是 GBK？BOM 在不在？有没有被其他编辑器偷偷改过？没查实锤就调设置，只会让问题更难回溯。
