ConvertToUTF8插件未生效需三步验证：先手动Reopen with Encoding→Chinese (GBK)使右下角变为“UTF-8 (ConvertToUTF8)”确认激活；再检查设置中convert_on_load/convert_on_save均为true；最后确保default_encoding_on_save设为"UTF-8"且文件有写权限。
ConvertToUTF8插件没生效？先确认它真正在工作
插件安装≠自动接管编码——ConvertToUTF8默认只对“已识别为非UTF-8”的文件触发转换，而它不负责解码显示。如果你打开一个GBK文件，右下角仍显示UTF-8（不是UTF-8 (ConvertToUTF8)），说明插件根本没启动。
验证方式：打开乱码文件后，手动点击右下角编码名 → Reopen with Encoding → 选Chinese (GBK)，等中文正常显示；此时再看右下角，若变成UTF-8 (ConvertToUTF8)，才表示插件已激活。
- ST4用户注意：
Package Control里搜到的ConvertToUTF8基本是失效镜像，必须手动下载原作者仓库seanliang/ConvertToUTF8的master分支 zip，解压重命名为ConvertToUTF8，拖进Packages目录 - 插件首次启用需“触发”：必须先用正确编码（如
Chinese (GBK)）手动重开一次文件，它才会记录该文件编码并后续自动处理 - 状态栏没变？检查
Preferences → Package Settings → ConvertToUTF8 → Settings，确认"convert_on_load": true和"convert_on_save": true均为true
Save with Encoding → UTF-8 才是真正转码动作，不是状态栏点一下就完事
很多人以为右下角点UTF-8就转码成功了，其实那只是切换了解码方式，磁盘文件字节完全没动。真正把内容写成UTF-8的，只有Save with Encoding → UTF-8这一步。
操作前务必确认：当前文件已用Chinese (GBK)等正确原始编码打开，且中文清晰可读；否则保存后就是双乱码，不可逆。
- 别选
UTF-8 with BOM：Sublime 默认保存无BOM UTF-8，选带BOM会导致部分工具（如Python解释器、Makefile）报错 - 保存后立刻关闭再重开，右下角应稳定显示
UTF-8（无括号后缀），且用xxd 文件名 | head能看到开头没有\xef\xbb\xbf - 如果保存失败或静默丢字，大概率是文件含GB18030混合变体或异常控制字符，建议先用Notepad++转一次再回Sublime验证
fallback_encoding 在 ST4 已彻底失效，default_encoding_on_save 才管用
ST4移除了fallback_encoding，你在设置里加"fallback_encoding": "Chinese (GBK)"完全无效。新建空文件时右下角显示什么编码，由default_encoding控制；但Ctrl+S实际写入磁盘的编码，只听default_encoding_on_save的。
如果你发现新建文件敲中文后保存仍是乱码，问题一定出在这里。
- 必须在
Preferences → Settings（用户设置）中显式添加："default_encoding_on_save": "UTF-8" -
default_encoding仅影响新建文件右下角标识和“另存为”对话框默认选项，不影响保存行为 - 插件配置里的
encoding_list只用于检测候选集，不覆盖default_encoding_on_save的写入规则
文件权限、路径挂载、只读属性会让 ConvertToUTF8 完全失效
插件只在有写入权限的前提下工作。它对只读文件、无写权限目录、远程挂载路径（如SMB/NFS）、符号链接指向的文件，全部静默跳过——不会报错，也不会提醒，你看到的还是乱码。
这类问题常出现在协作项目、Docker容器内编辑、或挂载Windows共享目录的Mac/Linux上。
- 检查文件权限：
ls -l 文件名，确保你有w权限；若为-r--r--r--，先chmod u+w 文件名 - 远程挂载路径下，插件无法调用系统
chardet库，检测准确率暴跌，建议本地转码后再同步 - 符号链接文件需确保目标路径可写，且
Packages目录本身不在只读文件系统上
(ConvertToUTF8)后缀，再查default_encoding_on_save是否设对，最后确认文件能写。这三个点漏掉任何一个，都只会让你对着乱码干瞪眼。 
