先用reopen with encoding选对原始编码（如chinese (gbk)），再save with encoding→utf-8转存；须用file -i（linux/macos）或notepad++（windows）确认真实编码，而非依赖sublime右下角显示。
直接修：先用 Reopen with Encoding 选对原始编码（比如 Chinese (GBK)），再用 Save with Encoding → UTF-8 转存。跳过第一步就保存，只会把乱码固化成双乱码。
怎么确认文件真是 GBK，而不是瞎猜右下角显示？
Sublime 右下角写的 UTF-8 或 Western (ISO 8859-1) 只是它当前怎么读，不是文件本来的编码。满屏“锟斤拷”时，它大概率正拿 UTF-8 解 GBK 字节流。
- Linux/macOS 下运行：
file -i 文件名，看输出里有没有charset=gbk - Windows 用户直接用 Notepad++ 打开，右下角明确标出
GBK或GB2312，比 Sublime 更可信 - 别信
detect_encoding: true：这个配置会让 Sublime 主动跳过 BOM 去试 GBK，反而把带 BOM 的 UTF-8 判成乱码，建议删掉
Reopen with Encoding 和 Save with Encoding 别点反了
这两个菜单项功能相反，点错一次就可能把能读的文件“转坏”。
-
Reopen with Encoding：只改当前视图怎么读文件，不写磁盘，安全。乱码后立刻点右下角编码名 →Reopen with Encoding→Chinese (GBK)；还不对就试Chinese (GB2312)，看到中文就停 -
Save with Encoding：真把内存里已解码的内容，按新编码重写到磁盘，不可逆。必须在Reopen with Encoding显示正常后才用，否则乱码会被固化 - 绝对别点老版本里的
Convert to UTF-8：它会静默重写文件且不提示，原始编码信息直接丢失
ST4 用户配 fallback_encoding 为什么总不生效？
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 或 "GBK" 是无效配置，等于没设。
- 正确写法是：
"fallback_encoding": "Chinese (GBK)"（注意括号、大小写、空格） - 这个设置只在“无 BOM + UTF-8 解码失败”时触发，带 UTF-8 BOM 的文件仍走 UTF-8，不会触发 fallback
- ST4 已彻底移除
fallback_encoding的自动兜底逻辑，它只影响极少数旧项目场景；真正控制保存行为的是default_encoding_on_save，但日常操作中手动Save with Encoding更可靠
最常被忽略的点是：混合编码项目里，同一目录下既有 UTF-8 无 BOM 的新脚本，又有 GBK 的旧配置——这时全局配置毫无意义，必须靠右下角手动切编码，或为项目单独建 .sublime-project 绑定编码规则。
