ConvertToUTF8插件仅实现临时解码显示而非自动转码，打开GBK等非UTF-8文件需手动执行“Decode with GBK”，保存仍按原编码写回，仅“Save with Encoding → UTF-8”才真正转码。
ConvertToUTF8插件根本不能“转换文件编码”
它只是让Sublime Text能「正确读取并临时显示」非UTF-8编码的文件（比如GBK、BIG5、Shift-JIS），保存时仍按原编码写回——除非你手动另存为UTF-8。很多人装上就以为“自动转码了”，结果用Git提交、在其他编辑器打开或部署到Linux服务器时，中文全变乱码。
安装后必须手动触发解码，不是自动生效
插件默认只监听文件打开事件，但对已打开的文件、新建文件、粘贴内容完全无感。常见错误现象：Ctrl+R 重载后中文仍显示为，或者切换到其他标签页再切回来，GBK文件突然又变乱码。
- 打开GBK文件后，按
Ctrl+Shift+P→ 输入ConvertToUTF8: Decode with GBK手动指定解码方式 - 如果文件名含中文或路径有空格，插件可能无法自动识别编码，必须强制选一次
- 不建议依赖
auto_detect_encoding配置项——它靠BOM和字节特征猜，对纯中文文本（尤其无BOM的GBK）准确率极低
保存行为取决于你是否执行“另存为UTF-8”
ConvertToUTF8不会修改文件原始编码，它只影响Sublime内部的文本渲染缓冲区。你点 Ctrl+S 保存，文件还是以原来编码（如GBK）写回磁盘；只有显式执行 File → Save with Encoding → UTF-8，才会真正转码并覆盖原文件。
- 误操作风险高：有人反复点保存，以为“已经转好了”，其实只是把乱码又存了一遍
- 若项目要求统一UTF-8，建议配合
SaveOnFocusLost插件 + 自定义保存钩子，但需额外写Python脚本，原生ConvertToUTF8做不到 - 注意Windows记事本保存的UTF-8带BOM，而Sublime默认保存无BOM；若对接旧系统（如某些PHP环境），需在设置里开
ensure_newline_at_eof_on_save并手动处理BOM
与其它编码插件冲突时优先级混乱
如果你同时装了 ChineseLocalization、YAPF 或自定义build system，它们可能劫持on_load事件或覆盖encoding元数据，导致ConvertToUTF8解码失败且无提示。
- 典型错误信息：
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc1 in position 0—— 实际是插件没抢到解码权，Sublime用UTF-8硬解GBK头字节 - 排查方法：禁用所有插件，只留ConvertToUTF8，逐个启用对比
- 关键配置项
convert_on_save默认是false，设成true也不会自动转存，它只对“检测到非UTF-8且用户确认转存”的场景起作用，且仅限当前会话
