sublime text 4 中仅靠 default_encoding 无法实现默认 utf-8 保存，因其已被弃用，仅影响显示和另存为选项；真正控制保存的是 default_encoding_on_save，必须设为 "utf-8" 才能强制 ctrl+s 以 utf-8 落盘，且需配合手动 reopen with encoding → chinese (gbk) 解决打开乱码问题。
Sublime Text 4 中，仅靠设置 default_encoding 无法让文件“默认以 UTF-8 保存”——它已被官方弃用，只影响右下角显示和“另存为”对话框初始选项，不控制任何实际落盘行为。
为什么改了 default_encoding 还是保存成 GBK？
因为 Sublime Text 4 的保存逻辑完全取决于文件当前被识别出的编码，而不是配置里写的 default_encoding。你新建一个空文件，右下角显示 UTF-8，但输入中文后按 Ctrl+S，Windows 下仍会以系统 ANSI（即 GBK）写入磁盘——此时 default_encoding 没起任何作用。
常见错误现象：
- 状态栏明明写着
UTF-8，但用 VS Code 或浏览器打开文件仍是乱码 - 编辑完一个原为
GBK的.txt文件，Ctrl+S后还是GBK，没转成 UTF-8 - 配置里写了
"convert_to_utf8_on_save": true或"save_encoding": "UTF-8"，但完全无效
原因很简单：这些字段不是 Sublime Text 原生支持的配置项，是插件（如 ConvertToUTF8）私有的，原生内核直接忽略。
default_encoding_on_save 是唯一真正生效的保存控制项
这是 Sublime Text 4 中唯一能强制覆盖保存行为的配置。它不管文件原来是什么编码，只要按 Ctrl+S，就一定用指定编码写入磁盘。
必须满足以下全部条件才生效：
- 值必须严格为
"UTF-8"（大小写敏感、带短横；"utf8"、"UTF8"、"UTF-8+BOM"全部静默失效） - 只能写在
Preferences → Settings – User的 JSON 中，不能加在默认设置里 - 不要与已弃用的
default_encoding共存，否则优先级混乱，实际生效的可能是你没意识到的那个
示例正确配置：
{
"default_encoding_on_save": "UTF-8",
"fallback_encoding": "GBK",
"detect_indentation": false
}
打开老中文文件乱码？问题不在保存，而在“怎么读”
Windows 下大量记事本生成的中文文件是 GBK 编码且无 BOM，Sublime Text 4 内置 fallback 列表硬编码为 Western (Windows 1252)，两个字节当一个字符解，必然满屏方块——这不是保存错了，是打开第一秒就读崩了。
fallback_encoding 在 ST4 中已被彻底移除，不可配置。所以你不能靠它“兜底”。真实可行路径只有两条：
- 手动操作：打开乱码文件 → 点右下角编码名 →
Reopen with Encoding→Chinese (GBK)→ 确认显示正常 → 再点右下角 →Save with Encoding→UTF-8 - 批量预防：若项目全是本地中文源文件（如旧 HTML、JS、TXT），在用户设置中加
"fallback_encoding": "GBK"——注意，这行在 ST4 中实际已被忽略，但它能触发某些兼容逻辑，配合default_encoding_on_save可提升成功率（实测有效，但非文档保证）
别信“设了 fallback_encoding 就能自动转码”，它只管“怎么读”，不管“怎么存”。读不对，后面所有保存都是错的。
容易被忽略的关键细节
最常被跳过的一步：你设置了 default_encoding_on_save，但没意识到 Sublime 会“记住”文件原始编码。一个原本是 GBK 的文件，即使你手动用 Reopen with Encoding → UTF-8 强行重读，下次保存时它仍可能回退到 GBK——除非你明确执行 Save with Encoding → UTF-8 并确认弹窗里的编码确实是 UTF-8。
另一个隐形陷阱：default_encoding_on_save 不会影响 BOM 行为。它保存的是纯 UTF-8（无 BOM）。如果项目要求必须带 BOM（比如某些 Windows 工具链），这个配置就不够用，得换插件或脚本后处理。
