必须用file -i（linux/macos）或notepad++（windows）确认文件真实编码，而非依赖sublime右下角显示的“utf-8”等字样，因其仅表示当前解码方式，并非文件真实编码；查bom可用xxd命令验证。
怎么确认文件真实编码，而不是靠右下角状态栏瞎猜
Sublime 右下角显示的 UTF-8 或 Western (Windows 1252) 只代表它“当前用什么解这个文件”，不是文件真实编码。你看到方块字，恰恰说明它正用错的方式读——比如拿 UTF-8 规则去解 GBK 字节流 e4 bd a0 e5 a5 bd，结果必然乱。
必须实锤验证：
- Linux/macOS：运行
file -i 文件名，看输出里charset=gbk或charset=utf-8 - Windows：用 Notepad++ 打开 → 右下角直接显示 “GBK”“UTF-8-BOM”，比 Sublime 更可信
- 查 BOM：运行
xxd 文件名 | head -n1，输出含ef bb bf就是带 BOM 的 UTF-8
fallback_encoding 为什么设成 "UTF-8" 完全无效
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置，等于没设。Sublime 内部只认它注册的界面名称，比如 "Chinese (GBK)" 或 "Western (ISO 8859-1)"。
常见错误写法和对应正确值：
- 错：
"fallback_encoding": "UTF-8"→ 无效，忽略 - 对：
"fallback_encoding": "Chinese (GBK)"→ 覆盖绝大多数中文旧文件 - 对：
"fallback_encoding": "Chinese (GB2312)"→ 老 Windows 记事本导出文本 - 对：
"fallback_encoding": "Western (Windows 1252)"→ 含英文+少量中文的日志
注意：这个字段只在文件无 BOM、且 default_encoding 不匹配时才生效，它不干预已有 BOM 的文件。
default_encoding 和 fallback_encoding 必须配着用
default_encoding 控制新建文件和 Save with Encoding 弹窗默认选啥；fallback_encoding 负责兜底打开无 BOM 的老文件。单设一个解决不了全部问题。
典型组合（放进 Preferences → Settings – User）：
- 纯新项目（全 UTF-8）：
"default_encoding": "UTF-8", "fallback_encoding": "UTF-8"—— 但注意：fallback_encoding写"UTF-8"实际无效，应改用"UTF-8 with BOM"或放弃此字段，靠 BOM 识别 - 混合项目（GBK 老文件 + UTF-8 新脚本）：
"default_encoding": "UTF-8", "fallback_encoding": "Chinese (GBK)" - 绝对禁用自动探测：
"detect_encoding": false，否则 Sublime 可能跳过 BOM 去试 GBK，把带 BOM 的 UTF-8 判成乱码
Save with Encoding → UTF-8 到底干了什么
这是唯一真正改磁盘内容的动作：把内存里已正确解码的 Unicode 字符，按 UTF-8 编码规则重新写回文件。它不依赖插件，失败会报错。
关键前提：必须先用 Reopen with Encoding → Chinese (GBK) 确保中文正常显示，再点 Save with Encoding → UTF-8。跳过第一步直接保存，等于把 GBK 字节当 UTF-8 解一遍再写出去，结果是双重乱码，基本不可逆。
顺手加这一行防坑："save_with_bom": false，否则 Python、Git、Shell 脚本会因开头的 \xef\xbb\xbf 报 SyntaxError: Non-UTF-8 code starting with '\xef'。
混合编码项目最容易被忽略的是：全局设置救不了所有文件。同一目录下既有 UTF-8 无 BOM 的新脚本，又有 GBK 的旧配置，这时候得靠右下角手动切编码，或者用项目专属配置绑定规则——这点等 Git 提交失败才反应过来，就晚了。
