先手动指定原始编码（如Chinese (GBK)）使中文正常显示，再执行Save with Encoding→UTF-8真正转码；ConvertToUTF8仅在正确解码后辅助保存，不解决初始乱码。
Sublime 打开中文文件显示乱码，不是插件没装对，而是你还没告诉它“这个文件本来就是 GBK”。ConvertToUTF8 插件本身不解决乱码——它只在你已经正确解码的前提下，帮你把编辑后的内容以 UTF-8 保存。真正起效的第一步，永远是手动指定原始编码。
怎么让乱码文件立刻显示正常？
别点设置、别改配置，先救眼前问题：
- 打开乱码文件 → 点击右下角状态栏的当前编码名（比如
UTF-8或Western (ISO 8859-1)）→ 选Reopen with Encoding→Chinese (GBK) - 如果还是乱码，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文能看清，就说明原始编码判断对了 - 此时你看到的“正常中文”只是 Sublime 在内存里用 GBK 解出来的 Unicode 字符串，磁盘上文件一个字节都没变
- 如果点完
Chinese (GBK)后反而更乱，说明原始编码不是 GBK，别硬扛，换其他选项再试
ConvertToUTF8 插件到底该不该装？
它现在基本是个“历史兼容补丁”，不是必选项：
- Sublime Text 4（Build 4100+）已内置 GBK/Big5 自动探测，多数场景下
ConvertToUTF8反而会干扰原生逻辑，导致状态栏编码显示错乱或保存行为异常 - 如果你用的是 Sublime Text 3 或老项目里一堆无 BOM 的 GBK 文件，插件仍有价值；但必须从 GitHub 手动安装原作者仓库（
seanliang/ConvertToUTF8），Package Control 里搜到的几乎全是过期镜像或改名版（如CTU8），有兼容风险 - 插件生效的前提是你已通过
Reopen with Encoding正确加载内容；它不会自动猜对编码，也不会把 UTF-8 文件“转出”成 GBK - 装了插件后，
Save with Encoding → UTF-8这一步仍不可跳过——插件不改磁盘，只帮你把内存里的 Unicode 按 UTF-8 编码写回去
真正把文件变成 UTF-8 的唯一动作
很多人以为点一下状态栏就转码了，其实那只是换了解码方式。让文件磁盘内容真正变成 UTF-8，只有这一步：
- 确认当前文件已用正确编码（如
Chinese (GBK)）打开，中文显示无误 - 菜单栏
File → Save with Encoding → UTF-8（注意：不是UTF-8 with BOM） - 保存后关闭再重开，右下角应显示
UTF-8，且中文依然正常 - 如果保存后别人用记事本打开还是乱码，说明你漏了上一步——文件根本没被正确识别为 GBK，直接保存只会把乱码字节按 UTF-8 再编码一遍，双乱码
为什么改了设置还是乱码？常见坑在哪
最常被忽略的不是操作顺序，而是 Sublime 的缓存机制和编码标识规则：
- Sublime 会记住每个文件上次使用的编码，关掉再重开仍沿用；想覆盖，必须手动
Reopen with Encoding，不能只靠fallback_encoding -
fallback_encoding必须填 Sublime 内置名称，比如Chinese (GBK)，填GBK或gbk无效 - 带 BOM 的 UTF-8 文件会被优先识别为
UTF-8，fallback_encoding不触发；但无 BOM 的 UTF-8 中文文件容易被当成 Latin-1，这时fallback_encoding才关键 - 装了
ConvertToUTF8后又配了default_encoding和fallback_encoding，两套逻辑打架，反而更难排查——建议二选一：要么纯原生流程（推荐），要么卸载插件只用它
事情说清了就结束。真正的编码转换只发生在 Save with Encoding → UTF-8 那一刻，而不是装插件、改设置、点状态栏的任意其他操作。最容易被忽略的，是“先确认原始编码”这个前提——没有它，后面所有动作都是在错误基础上叠楼。
