sublime text 不支持项目级 default_encoding 配置，因其编码检测在文件打开瞬间完成且该设置仅在全局或语法级别生效；.sublime-project 中的 settings 无法覆盖。
Sublime 无法为不同项目设置独立的文件编码（default_encoding）——这个设置只在全局或语法级别生效，项目级 settings 中写入 "default_encoding": "UTF-8" 完全无效。
为什么 default_encoding 不支持项目级配置
Sublime Text 的编码检测与加载逻辑发生在文件打开瞬间，早于项目上下文加载；default_encoding 是一个「会话级」而非「项目级」配置项，它只被读取一次（启动时或通过菜单手动触发），不响应 .sublime-project 中的 settings 字段。
常见错误现象：
- 在 .sublime-project 的 settings 里写了 "default_encoding": "GBK"，保存后重启项目，新建文件仍是 UTF-8
- 手动用 File → Reopen with Encoding → GBK 可临时切换，但关掉再打开又回 UTF-8
- 控制台执行 view.settings().get("default_encoding") 始终返回 None，说明该键根本未被视图继承
真正能影响单个文件编码的行为有哪些
虽然不能“默认用 GBK”，但以下操作可对特定文件或场景生效：
-
File → Save with Encoding：保存时强制指定编码，下次打开即按此编码读取（前提是文件头无 BOM 且未被 Sublime 自动误判） -
File → Reopen with Encoding：对已打开文件重新以指定编码解析，适合修复乱码，但不持久 - 在
.sublime-project的folders下为某路径加"encoding": "GBK"——无效，Sublime 忽略该字段 - 用插件如
ConvertToUTF8或EncodingHelper实现自动识别 + 转换，但它们作用于文件粒度，不是项目配置
多项目编码管理的实际可行方案
如果你必须让 A 项目默认用 UTF-8、B 项目默认用 GBK，只能绕过「默认编码」机制，改用行为约束：
- 在 B 项目根目录放一个空的
README.gbk文件，用File → Open with Encoding → GBK打开它，然后File → Save with Encoding → GBK——之后所有新.txt或无扩展名文件，在该窗口中右键「New File」并立刻Save with Encoding，Sublime 会记住最近一次成功保存的编码 - 为不同项目配专属构建系统（
build_systems），在cmd中调用iconv或nkf预处理，把源文件转成统一编码再交给编译器/解释器 - 用
Project → Edit Project添加"file_exclude_patterns": ["*.tmp", "*.swp"]等，避免非目标编码的临时文件干扰，减少误操作
最常被忽略的一点：Sublime 的「自动编码检测」本身就很弱，尤其对无 BOM 的 GBK/Big5 文件。与其纠结项目级默认值，不如在团队中统一约定 BOM + UTF-8，或用脚本在 CI 流程中强制校验和转换。
