sublime text 4 中 default_encoding 已弃用，仅影响显示和另存为选项，不控制实际编码行为；真正控制保存的是 default_encoding_on_save（设为"utf-8"），而打开无bom文件需手动 reopen with encoding → chinese (gbk) 再 save with encoding → utf-8。
Sublime Text 无法靠改 default_encoding 就让新建、打开、保存全走 UTF-8——它在 ST4 中已彻底弃用，只影响右下角显示和“另存为”对话框初始选项，不控制任何实际编码行为。
为什么改了 default_encoding 还是乱码？
因为 Sublime Text 实际编码逻辑分三阶段：打开、编辑、保存，每个阶段由不同配置控制。你看到状态栏写着“UTF-8”，只是当前内存内容的解码方式，不代表磁盘文件是 UTF-8，也不代表下次保存就会用 UTF-8。
-
default_encoding已被官方标记为“已弃用”，加了它，新建文件右下角可能显示 UTF-8，但空文件保存后根本没写入字节；输入中文再保存，Windows 下仍大概率落盘为 GBK - 网上流传的
"convert_to_utf8_on_save": true是 ConvertToUTF8 插件私有字段，原生 Sublime 完全不识别，加了也白加 - 点右下角编码名（比如点一下“GBK”）只是重解析当前内存内容，不改磁盘字节，也不转码——越点越乱
default_encoding_on_save 才是真正控制保存编码的开关
这是 Sublime Text 4 中唯一能强制覆盖保存行为的配置项。它不管文件原来是什么编码，只要按 Ctrl+S，就一律用指定编码写入磁盘。
- 必须设为
"UTF-8"（注意大小写和短横，"utf8"、"UTF-8+BOM"、"UTF8-BOM"都会静默失效） - 设了之后，打开一个 GBK 编码的 .txt，编辑完直接
Ctrl+S，Sublime 会把内存里的 Unicode 字符串重新编码为 UTF-8 字节写入——相当于自动转码 - 它不改变打开逻辑，也不影响显示，只管“落盘那一刻”。所以必须和
fallback_encoding配合使用，否则打开阶段就失败了
fallback_encoding 决定无 BOM 文件怎么打开
Windows 下大量记事本保存的中文文件是 GBK 编码且无 BOM，Sublime 默认 fallback 到 Western (Windows 1252)，两个字节当一个字符读，必然满屏方块——这不是设置错了，是解码策略没对上。
- ST4 彻底移除了
fallback_encoding的可配置能力，所谓“全局兜底编码”不复存在；你看到的 fallback 行为来自内置硬编码列表，不可修改 - 如果你主要处理本地老项目（.txt、.html、.js 等无声明编码的中文文件），必须手动干预：先
File → Reopen with Encoding → Chinese (GBK)，确认显示正常后再Save with Encoding → UTF-8 - 别信“设了 fallback 就能自动转码”——它只管“怎么读”，不管“怎么存”；读不对，存再多次也是双乱码
带 BOM 的 UTF-8 怎么配？
Sublime 原生支持 "UTF-8 with BOM"，但仅此一种写法有效。其他如 "UTF8-BOM"、"UTF-8+BOM"、"UTF-8 BOM" 全部静默失效，回退到系统 locale 或默认 fallback。
- 要带 BOM，必须写成：
"default_encoding_on_save": "UTF-8 with BOM" - 带 BOM 的文件在部分 Windows 工具（如旧版 IE、某些批处理脚本）中兼容性更好，但 Git 会警告、Node.js 可能报错
Unexpected token in JSON（BOM 占三个字节EF BB BF） - 绝大多数现代场景推荐无 BOM 的
"UTF-8"，更干净、更通用
最易被忽略的一点：你改的配置是否生效，取决于 Sublime 当前识别出的“文件编码状态”。这个状态不是靠设置决定的，而是由打开时的解码结果、历史保存行为、甚至文件头字节共同维持的。哪怕你配对写了 default_encoding_on_save 和 fallback_encoding，只要第一次打开就误判为 GBK，后续所有保存都会沿用那个误判结果——直到你手动 Reopen with Encoding。
