必须逐个执行Reopen with Encoding → Chinese (GBK)确认中文正常后，再Save with Encoding → UTF-8；批量操作不可行，因Sublime不自动识别真实编码，且fallback_encoding在ST4中已失效。
汉化不影响乱码修复逻辑，批量乱码的本质仍是单个文件的编码识别错误——必须逐个确认真实编码再重载，不存在“一键全修”的安全方案。
Reopen with Encoding 为什么不能批量点 Chinese (GBK)
Sublime Text 不会自动判断每个文件的真实编码，Reopen with Encoding 是视图级操作，只作用于当前打开的标签页。批量选中多个文件后右键 → “Reopen with Encoding” 菜单项根本不会出现；即使写插件强行触发，对 UTF-8 文件点 Chinese (GBK) 会立刻变成双乱码（比如“测试”变“娴嬭瘯”），且无法撤销。
- 真实编码可能是
GBK、GB2312、GB18030或带 BOM 的UTF-8，混在一个目录里很常见 - Linux/macOS 下用
file -i *.txt可批量看charset=字段，Windows 用户建议先用 Notepad++ 批量拖入 → 查看状态栏编码标识 - 别信“按文件扩展名统一设编码”的做法：
.conf可能是 GBK，.py必须是 UTF-8，硬配会出事
fallback_encoding 在 ST4 中已失效，别再配它
Sublime Text 4 彻底移除了 fallback_encoding 字段，你在用户设置里写 "fallback_encoding": "Chinese (GBK)" 完全不起作用。官方明确用 default_encoding_on_save 控制保存行为，而读取阶段只依赖 BOM 或手动干预。
- 真正生效的配置只有：
"default_encoding_on_save": "UTF-8"（强制 Ctrl+S 以 UTF-8 写入） -
"default_encoding"已被标记为“已弃用”，它只影响新建空文件右下角显示和“另存为”对话框默认项 - 删掉配置里所有
detect_encoding: true—— 这个开关会让 Sublime 主动跳过 BOM 去试 GBK，把带 BOM 的 UTF-8 文件判成乱码
Save with Encoding 前必须验证内存内容是否真正确解码
点 Save with Encoding → UTF-8 不是“修复动作”，而是“固化动作”。如果当前视图里还是“锟斤拷”，保存后就是永久双乱码，Git 提交、Python 解释器都会报错。
- 验证方法：复制任意一段中文 → 粘贴到新文件，看是否正常；或用
cat命令在终端输出该段内容 - 保存后立即用
xxd 文件名 | head -n1检查开头：无ef bb bf才算干净的 UTF-8（BOM 已禁用） - 若保存失败或静默丢字，大概率是文件含 GB18030 混合变体或不可见控制字符，建议先用 Notepad++ “转为 UTF-8 无 BOM”再回 Sublime
最麻烦的是混合编码项目——同一目录下既有 UTF-8 脚本又有 GBK 配置文件，全局设置毫无意义。得靠右下角手动切换，或者用 .sublime-project 绑定路径规则，这点不提前做，等 CI 构建失败才反应过来就晚了。
