default_encoding_on_save才是控制Ctrl+S保存编码的配置项，它强制以指定编码写入磁盘；default_encoding已弃用，仅影响显示和“另存为”初始选项，不控制实际保存。
default_encoding_on_save 才是真正控制 Ctrl+S 保存编码的配置项
Sublime Text 4 中 default_encoding 已被官方明确标记为“已弃用”，它只影响新建文件右下角显示的编码名、以及“另存为”对话框的初始选项，**完全不控制实际保存行为**。你看到状态栏写着“UTF-8”，不代表磁盘上写入的是 UTF-8 字节——尤其在 Windows 下，空文件或中文输入后直接保存，大概率仍是 GBK 编码。
真正起作用的是：default_encoding_on_save。它强制每次按 Ctrl+S 时，将当前内存中的 Unicode 内容以指定编码重新编码写入磁盘，不管原文件是什么编码。
- 必须设为
"UTF-8"（注意大小写、短横，"utf8"、"UTF-8+BOM"、"UTF8-BOM"全部静默失效） - 它不改变打开逻辑，也不影响显示，只管“落盘那一刻”
- 设了之后，打开一个 GBK 编码的
.txt，编辑完直接Ctrl+S，Sublime 就会把内容转成 UTF-8 字节写入——相当于自动转码 - 不要同时写
save_encoding或convert_to_utf8_on_save，它们不是原生字段，Sublime 会忽略
fallback_encoding 决定无 BOM 中文文件能否正常打开
Windows 下大量记事本生成的中文文件是 GBK 编码且无 BOM，Sublime Text 4 已彻底移除 fallback_encoding 的可配置能力，其 fallback 行为来自内置硬编码列表（默认尝试 Western (Windows 1252)），无法修改。这就是为什么一打开老 .txt 就满屏方块——不是设置错了，是解码策略根本没对上。
你无法通过配置让 ST4 “自动猜对 GBK”，但可以绕过：先手动干预，再靠 default_encoding_on_save 固化结果。
- 打开乱码文件 →
File → Reopen with Encoding → Chinese (GBK)（注意：这是界面名称，不是配置项值） - 确认中文显示正常后 →
File → Save with Encoding → UTF-8 - 此后该文件再编辑、
Ctrl+S，就会走default_encoding_on_save路径，稳定落盘为 UTF-8 - 别点右下角编码名选“Convert to UTF-8”——那只是内存转码，不保存；必须显式执行
Save with Encoding
用户设置里不要出现 default_encoding
default_encoding 不仅无效，还会干扰判断。它在 ST4 中优先级低于 default_encoding_on_save，且与后者共存时可能引发行为不一致：比如新建文件右下角显示 UTF-8，但输入中文后保存仍落盘为 GBK。
正确做法是：打开 Preferences → Settings – User，只保留必要字段，例如：
{
"default_encoding_on_save": "UTF-8",
"detect_indentation": false,
"trim_automatic_white_space": true
}
- 删掉所有
"default_encoding": ...行 - 删掉所有插件私有字段，如
"convert_to_utf8_on_save": true（原生不识别） -
detect_indentation建议关掉，避免某些混合缩进文件触发意外重解析 - 不需要重启，改完保存即生效
跨平台协作前务必确认文件真实编码
Sublime 显示状态栏写着 UTF-8，不代表磁盘字节就是 UTF-8。最可靠的方式是用命令行验证：
- Linux/macOS：
file -i filename.txt或iconv -l | grep -i utf配合转换测试 - Windows：
PowerShell Get-Content -Encoding UTF8 filename.txt若报错，说明不是真 UTF-8 - 编辑器内右下角显示的编码名，只是 Sublime 当前用于解码内存内容的“解释方式”，和文件实际字节无关
- 多人协作中，一个被误标为
UTF-8的 GBK 文件，会在其他编辑器里彻底崩坏——这种问题往往要等到 CI 构建失败才暴露
