converttoutf8 在 sublime text 4 中不工作，因其核心机制与 st4 新 api 冲突，异步生命周期未适配，配置无效；应改用原生配置 default_encoding 和 save_encoding 等项精准控制 gbk 文件的打开与保存。
ConvertToUTF8 插件为什么在 sublime text 4 里不工作
Sublime Text 4 内置了更完善的编码自动检测和 UTF-8 处理逻辑，ConvertToUTF8 的核心机制（比如 hook on_load 强制转码、拦截保存逻辑）与 ST4 的新 API 冲突，导致插件加载失败或完全静默——你改了文件编码，它也不触发转换，打开 GBK 文件还是乱码。
- ST4 默认启用
detect_encoding，会优先信任 bom 或文件头部字节特征，ConvertToUTF8的强制覆盖逻辑被绕过 - 插件未更新适配 ST4 的
on_load_async和on_post_save_async异步生命周期，旧版回调直接被忽略 - 即使插件显示“已启用”，
Preferences → Package Settings → ConvertToUTF8 → Settings里的配置也基本无效
不用 ConvertToUTF8，ST4 原生怎么正确打开 GBK/GB2312 文件
靠插件不如靠配置。ST4 自带的编码识别能力足够强，关键是告诉它“哪些扩展名默认用什么编码打开”，而不是等它猜错再补救。
- 打开
Preferences → Settings – Syntax Specific（注意是 Syntax Specific，不是普通 Settings） - 在右侧面板添加：
"default_encoding": "GBK", "fallback_encoding": "GBK" - 保存后，该语法（如 Plain Text、Python、HTML）下新建/打开无 BOM 的 .txt/.log/.bat 等文件，就会默认用 GBK 解码
- 对已有乱码文件：右下角点击当前编码名（如 “UTF-8”）→ 选 “Reopen with Encoding → GBK”，立刻恢复；之后可按 Ctrl+Shift+P 输入
Set Encoding: GBK锁定
保存时避免二次乱码：别让 ST4 把 GBK 文件存成 UTF-8
很多人只解决“打开乱码”，却在保存时把原本是 GBK 的文件悄悄转成 UTF-8，导致 windows 记事本、老旧工具打不开——这不是编码问题，是保存策略失控。
- 关闭自动转存：在全局
Settings中加"save_with_encoding": false，禁用 ST4 默认的“保存时转 UTF-8”行为
- 手动指定保存编码：乱码文件正常打开后，Ctrl+Shift+P → 输入
Save with Encoding→ 选GBK（不是 UTF-8） - 如果常处理日志类文件，可在
Settings – Syntax Specific加"default_line_ending": "windows", "save_encoding": "GBK"，确保换行和编码都匹配 Windows 生态
哪些场景仍建议放弃 ST4 + 手动配置，换用其他方案
如果你频繁切换 GBK / UTF-8 / Big5 / Shift-JIS 文件，且文件无统一扩展名、无 BOM、混杂多种编码——ST4 原生方案会反复失效，这时候硬调配置不如换工具。
- 临时查看：用 VS Code 配合
Encoding Selector插件，右下角点编码名可快速重载，支持模糊识别（如 “GBK-like”） - 批量处理：命令行用
iconv -f GBK -t UTF-8 file.txt > file_utf8.txt转码，比在编辑器里点十次更可靠 - 长期维护老项目：直接切到 Notepad++，它的编码菜单最直觉，且对无 BOM 的 GBK 兼容性至今优于多数现代编辑器
ST4 的编码模型是面向 UTF-8 优先设计的，强行让它“兼容一切”反而容易在保存路径、剪贴板交互、插件链路上出不可见的错。真要稳，就接受它“擅长 UTF-8，其余靠精准配置”，别指望一个插件兜底。