sublime text 编码问题核心在于区分新建、打开、保存三阶段：default_encoding已弃用；default_encoding_on_save控制保存编码；fallback_encoding决定无bom文件的打开解析；状态栏显示仅为当前解码方式，不改变文件实际编码。
新建文件默认编码不是靠 default_encoding 就能搞定的
Sublime Text 新建空白文件时，界面显示为 UTF-8，但这个“显示”不等于“已写入 BOM”或“已绑定保存行为”。default_encoding 确实控制新建文件的初始编码标识，但它在 Sublime 中早已被弱化——官方明确标注为“已弃用”，实际生效依赖上下文。你改了它，新建文件右下角可能还是显示 UTF-8，但一保存，如果内容为空或没触发编码确认流程，它根本不会写入任何字节，更不会带 BOM。
真正起作用的是：default_encoding_on_save（仅影响保存动作）和 fallback_encoding（决定打开未知文件时怎么猜）。所以别只盯着 default_encoding 配，它现在更多是个兼容占位符。
-
default_encoding_on_save设为"UTF-8"：确保按 Ctrl+S 时默认走 UTF-8 编码写入 -
fallback_encoding设为"UTF-8"：让 Sublime 打开无 BOM、无声明的旧文件时，优先用 UTF-8 解析，而不是误判成Western (Windows 1252)或 GBK 导致满屏方块 - 不要设
"UTF-8 with BOM"：Sublime 不识别这个字符串，会静默失效或回退到系统 locale
打开旧文件乱码？不是设置错了，是解码逻辑没对上
你在 Windows 上双击一个记事本存的中文 .txt，打开全是 ，这不是因为你没设对 default_encoding，而是 Sublime 拿 fallback_encoding 去读了一个实际是 GBK 的文件——它把两个 GBK 字节当做一个 UTF-8 字符解，自然崩坏。
此时点右下角状态栏的编码名（比如点一下 UTF-8），只是让 Sublime “重解析当前内存内容”，不改磁盘字节，也不转码。你越点越乱，因为每次都是拿错的规则再解一遍错的字节。
- 正确做法：菜单栏
File → Reopen with Encoding → Chinese (GBK)（或GBK），先让内容正常显示 - 确认无误后，再执行
File → Save with Encoding → UTF-8，这才真正把 GBK 字节转成 UTF-8 字节写回磁盘 - 若频繁处理这类文件，建议安装
ConvertToUTF8插件，它会在打开时自动识别 GBK 并转为 UTF-8 显示，但注意：它默认保存仍回 GBK，如需统一存 UTF-8，得进插件配置关掉save_to_original_encoding
convert_to_utf8_on_save 是假选项，原生 Sublime 不支持自动转码保存
网上很多教程让你在用户设置里加 "convert_to_utf8_on_save": true，这行配置 Sublime 原生根本不认——它不是内置键名，属于某些插件（如老版 ConvertToUTF8）的私有字段。加了不仅无效，还可能导致配置解析失败（JSON 格式错误）。
Sublime 的保存行为永远基于当前文件“当前使用的编码”：如果你用 Reopen with Encoding → GBK 打开了文件，那 Ctrl+S 默认就以 GBK 保存；只有你手动执行过 Set Encoding → UTF-8，它才会以 UTF-8 保存。不存在“后台偷偷转码”这回事。
- 想强制某类文件总用 UTF-8 保存？装
File Encoding Manager插件，可按扩展名绑定默认保存编码（例如所有.py文件自动设为 UTF-8） - 想一键批量转项目里所有 GBK 文件？别指望 Sublime 内置功能，用命令行：
iconv -f GBK -t UTF-8 file.txt -o file_utf8.txt - 插件转换有边界：ConvertToUTF8 能帮你“看懂” GBK，但不能把 UTF-8 文件反向转成 GBK；它也不改文件磁盘编码，只是编辑时做内存映射
带 BOM 还是不带 BOM？多数场景该选无 BOM 的 UTF-8
Sublime 右下角能看到 UTF-8 和 UTF-8 with BOM 两个选项，但它们不是等价切换。前者是标准、干净的 UTF-8；后者开头多三个字节 EF BB BF，会导致 Python 解释器报 SyntaxError: Non-UTF-8 code starting with '\xef'，Git 提交时显示异常，Node.js 读取也可能出问题。
除非对接的系统（比如某些老旧 Windows 工具、IE6 时代的 ASP 页面）明文要求 BOM，否则一律用无 BOM 版本。Sublime 默认的 UTF-8 就是无 BOM 的，而 UTF-8 with BOM 只应在明确需要时手动选择。
- 新建文件后立刻要输中文？不用管 BOM，直接敲字，Ctrl+S 即按
default_encoding_on_save规则保存 - 已有文件带了 BOM 想去掉？
File → Reopen with Encoding → UTF-8 with BOM→ 全选复制 → 新建文件 → 粘贴 →Save with Encoding → UTF-8 - 插件如 ConvertToUTF8 默认不写 BOM，但它的配置项
write_bom若被设为true，就会悄悄加上——检查插件 settings 是否有这一行
编码问题从来不是改一个配置就能终结的事。它横跨新建、打开、编辑、保存、插件介入、跨平台协作多个环节，每个环节都可能卡住。最常被忽略的是：状态栏显示的编码名，只是 Sublime 当前“怎么读”，不是文件“本来是什么”；而保存动作永远忠于“当前怎么读”，不是“你想怎么存”。搞清这个前提，比背一百条配置项都管用。
