sublime text原生不支持新建即utf-8且自动带bom，真正起作用的是default_encoding_on_save（控制ctrl+s保存编码）和fallback_encoding（决定无bom文件打开时的解码兜底），default_encoding已弃用，仅影响右下角显示和另存为初始选项，不控制保存或打开逻辑。
Sublime Text 原生不支持“新建即 UTF-8 且自动带 BOM”这种一键式默认，真正起作用的只有 default_encoding_on_save 和 fallback_encoding；改 default_encoding 不仅无效，还可能干扰判断。
为什么改了 default_encoding 还是乱码？
因为 default_encoding 在 Sublime 官方文档中已被明确标记为“已弃用”。它只影响新建文件右下角的显示标识、以及“另存为”对话框的初始选项，完全不控制保存行为或打开逻辑。
- 你看到状态栏写着“UTF-8”，不代表文件磁盘字节就是 UTF-8 —— 空文件保存后根本没写入任何字节
- 点右下角编码名（比如点一下“UTF-8”）只是让 Sublime 用新规则重解析当前内存内容，不改磁盘字节，也不转码
- 网上流传的
"convert_to_utf8_on_save": true是 ConvertToUTF8 插件私有字段，Sublime 原生根本不识别，加了也白加
怎么让 Ctrl+S 强制保存为 UTF-8（无 BOM）？
必须设置 default_encoding_on_save，这是唯一决定“按 Ctrl+S 写入什么编码”的配置项。
- 在
Preferences → Settings – User右侧添加："default_encoding_on_save": "UTF-8" - 如果需要带 BOM（极少数 Windows 工具强制要求），则写成：
"default_encoding_on_save": "UTF-8 with BOM"—— 注意字符串必须一字不差，"UTF8-BOM"或"UTF-8+BOM"都会静默失效 - 不要同时设
save_encoding或convert_to_utf8_on_save，它们不是原生字段，Sublime 会忽略
为什么旧中文文件一打开就全是方块？
这不是新建问题，而是打开时解码失败：Windows 下大量 .txt 文件是 GBK 编码但无 BOM，Sublime 默认用 Western (Windows 1252) 去解，两个字节当一个字符读，必然崩坏。关键在 fallback_encoding。
- 设
"fallback_encoding": "GBK"：适合本地开发老项目，能直接正确打开记事本存的中文文件 - 设
"fallback_encoding": "UTF-8"：适合纯跨平台协作场景，但遇到 GBK 文件仍需手动File → Reopen with Encoding → Chinese (GBK)后再Save with Encoding → UTF-8 - 别信“设了 fallback 就能自动转码”——它只管“怎么读”，不管“怎么存”；读对了，才能安全地存成 UTF-8
最易被忽略的一点：default_encoding_on_save 和 fallback_encoding 必须配对使用，且不能和已弃用的 default_encoding 共存；否则优先级混乱，实际生效的可能是你没意识到的那个值。
