sublime text 4 中 default_encoding 已弃用，仅影响新建文件编码显示和另存为默认选项，不控制实际保存编码；真正控制保存编码的是 default_encoding_on_save，设为 "utf-8" 可强制静默转码保存；打开无 bom 的 gbk 文件仍会因硬编码 fallback 列表误判为 windows-1252 而乱码，需手动 reopen with encoding → chinese (gbk)，再 save with encoding → utf-8 才能固化为 utf-8。
Sublime Text 4 无法靠改 default_encoding 就让新建和保存都变成 UTF-8——它已弃用，且 ST4 彻底移除了 fallback_encoding，所谓“全局兜底编码”不复存在。你看到的乱码，90% 是因为打开无 BOM 的 GBK 文件时，ST4 按内置 fallback 列表（不可配）误判为 Windows-1252；而保存行为则完全取决于文件**当前被识别出的编码**，不是设置里写的什么。
为什么 Preferences → Settings 里加 default_encoding 没用？
ST4 文档明确标注 default_encoding 已弃用。它只影响：新建空文件右下角显示的编码标识、另存为对话框默认选中的编码项。它**不控制 Ctrl+S 的实际写入编码**，也不影响已有文件的打开逻辑。你加了 "default_encoding": "UTF-8"，新建文件右下角确实显示 UTF-8，但如果你立刻输入中文并保存，磁盘上字节仍是系统默认 ANSI（Windows 下即 GBK），因为 ST4 会按“当前文件编码”保存，而新文件初始编码状态是未定义的，实际落盘由底层机制决定。
default_encoding_on_save 才是真正控制保存编码的开关
这个配置项才是 ST4 中唯一能强制覆盖保存行为的字段。它告诉 Sublime：“不管文件原来是什么编码，只要我按 Ctrl+S，就一律用这个编码写入磁盘”。
- 必须设为
"UTF-8"（注意大小写和短横，不能是utf8或utf-8） - 它不改变文件打开方式，也不影响显示，只管“落盘那一刻”
- 如果文件原本是 GBK，你编辑后 Ctrl+S，Sublime 会把内存里的 Unicode 字符串重新编码为 UTF-8 字节写入——相当于自动转码
- 与
save_with_encoding不同，它无需弹窗确认，静默生效
打开旧 GBK 文件仍乱码？ST4 没有 fallback_encoding 可配
ST4 移除了该配置项，打开无 BOM、无声明的中文文件时，它依赖一套硬编码的 fallback 列表（顺序固定：UTF-8 → UTF-16 → Windows-1252 → ...），不会优先尝试 GBK。所以你双击一个老 .txt，大概率还是乱码。
此时必须手动干预：
- 右下角点击当前编码名（如
Western (Windows 1252)或空白）→ 选Reopen with Encoding→Chinese (GBK) - 确认中文显示正常后，再点右下角 →
Save with Encoding→UTF-8（不是UTF-8 with BOM） - 这一步才真正把磁盘文件变成 UTF-8；之后再开，ST4 能通过 BOM 或内容特征识别，不再乱码
别指望插件全自动解决——ConvertToUTF8 在 ST4 上兼容性差，常导致状态栏编码显示错乱或保存行为异常，官方也不再推荐。
最终推荐的用户设置（Preferences → Settings – User）
只需这三行，干净有效：
{
"default_encoding_on_save": "UTF-8",
"detect_indentation": false,
"ensure_newline_at_eof_on_save": true
}
detect_indentation 设为 false 是为了禁用 ST4 那个名字误导人的缩进探测逻辑（它实际也参与编码猜测），避免干扰；ensure_newline_at_eof_on_save 是良好习惯，与编码无关但建议开启。不要加 default_encoding、fallback_encoding 或 convert_to_utf8_on_save —— 它们在 ST4 中要么无效，要么冲突。
最关键的细节：所有转码动作都发生在“保存”那一刻，而不是“打开”或“设置更改后”。哪怕你配对正确，打开一个 GBK 文件仍需先 Reopen with Encoding 看清内容，再 Save with Encoding 固化 UTF-8。这步不能跳，也没法绕过。
