sublime text显示“涓枃”“锟斤拷”是因用utf-8解gbk字节流导致错解，应执行file→reopen with encoding→chinese (gbk)重读原始字节，而非点击状态栏切换编码；fallback_encoding须设为"chinese (gbk)"才生效，且仅对无bom且utf-8解码失败的文件触发。
Sublime Text 打开 GBK 文件显示“涓枃”“锟斤拷”，不是文件坏了，是它用 UTF-8 去解 GBK 字节流——改编码识别逻辑，比转文件更安全、更可控。
为什么点右下角 UTF-8 切成 GBK 没用？
状态栏点击编码名（比如 UTF-8）只是让 Sublime 用新编码重新解析当前内存里的字节，不改磁盘内容，也不修正已错解的文本。你先错解出一堆“锘?”，再拿 UTF-8 去解释这堆乱码字节，只会更糊。
真正该做的是：File → Reopen with Encoding → Chinese (GBK)——这是重读原始字节，不是“修复乱码”。只有这一步成功了，后续保存才有意义。
- 如果菜单里没有
Chinese (GBK)，说明没装编码支持插件，或系统编码标识未加载 - 选
GB2312有时也能凑合，但GBK是超集，优先试Chinese (GBK) - 千万别选
Western (Windows 1252)或ISO 8859-1，它们根本不支持中文
fallback_encoding 怎么设才生效？
fallback_encoding 不是“默认编码”，它是“自动检测失败后兜底用的编码”，只在“无 BOM + UTF-8 解码失败”时触发。Windows 下很多记事本生成的 GBK 文件不带 BOM，正好踩中这个条件。
打开 Preferences → Settings，在右侧用户设置中加这一行：
"fallback_encoding": "Chinese (GBK)"
注意：fallback_encoding 必须用 Sublime 内置的完整编码名，写 "GBK" 或 "gbk" 会被静默忽略。
-
default_encoding已被官方弃用，别配它；它只影响极少数 UI 场景，不控制文件读写 - 带 UTF-8 BOM 的文件仍走 UTF-8，不会触发
fallback_encoding - 这个设置对已打开的乱码文件无效，必须先手动
Reopen with Encoding恢复一次
ConvertToUTF8 插件要不要装？
装，但得清楚它干了什么、边界在哪：它在内存里把 GBK 转成 UTF-8 显示，编辑完再转回 GBK 保存，不碰磁盘原始字节——所以能保兼容，也容易出坑。
安装后务必检查配置（Preferences → Package Settings → ConvertToUTF8 → Settings）：
- 默认
"save_to_original_encoding": true，即保存回 GBK；如需统一存为 UTF-8，必须设为false - 旧版插件（尤其 ST3 时代）可能静默覆盖原文件且不备份；ST4（Build 4126+）更稳，但仍建议先关掉
convert_on_open测试单个文件 - 卸载插件后，残留的配置仍可能干扰原生逻辑，务必手动删掉 Package Settings 里的对应项
保存时怎么选编码才不埋雷？
显示正常 ≠ 可以随便保存。团队协作中硬塞 GBK 文件，Git diff 会崩、CI 构建会挂、Mac/Linux 用户打不开——Sublime 能读，不代表生态能认。
推荐做法是：Reopen with Encoding → Chinese (GBK) 恢复显示 → 编辑完成 → File → Save with Encoding → UTF-8。
- 保存后右下角状态栏会显示
UTF-8，确认无误再提交 - 如果必须保留 GBK（比如对接老旧银行系统），则用
Save with Encoding → Chinese (GBK)，但要确保所有协作者都配了相同 fallback 或插件 - 中文路径在 Windows 下打不开？不是编码问题，是 Sublime 的文件系统 API 解析不稳；临时解法：直接把文件拖进窗口，别用
File → Open对话框
最常被忽略的一点：fallback_encoding 和插件共存时，谁生效取决于文件是否有 BOM、是否触发自动检测失败、插件是否启用 convert_on_open——三者逻辑嵌套，不测试单个文件很难凭经验判断。动手前，先用一个确定是 GBK 的小文件验证整条链路。
