Sublime Text 配置同步后乱码主因是 fallback_encoding 和 default_encoding_on_save 在不同机器上实际值不一致；fallback_encoding 必须写为 "Chinese (GBK)" 等内部标识符而非 "UTF-8"，default_encoding_on_save 才控制真实保存编码，且需显式配置并确保配置文件本身为 UTF-8 无 BOM。
Sublime Text 配置同步后格式不对，根本不是“同步出错”，而是不同机器上 fallback_encoding 和 default_encoding_on_save 的实际值不一致，导致同一份配置文件在 A 机正常、B 机打开就乱码——尤其当同步的配置里混着中文注释或路径时。
右下角显示 “UTF-8” 却还是方块字？先看 fallback_encoding 实际生效没
状态栏显示的编码只是当前视图解码方式，不反映文件真实字节。真正决定“双击打开就乱码”的是 fallback_encoding：它只在文件无 BOM、且 Sublime 没法靠内容猜出编码时才起作用。
-
fallback_encoding不接受"UTF-8"这种标准名，必须写成"UTF-8"（ST4 兼容）或"Chinese (GBK)"（Windows 中文系统常见），写错等于没设 - 如果同步来的配置里有
"fallback_encoding": "UTF-8"，但在 Windows 机器上仍乱码，大概率是旧版 ST3 配置残留——ST3 不认这个值，得换成"Chinese (GBK)" - 别信
detect_encoding: true：它会让 Sublime 主动跳过 BOM 去试 GBK，结果把带 BOM 的 UTF-8 文件判成乱码，建议直接删掉这一行
同步后新建文件编码又变 Western (Windows 1252)？default_encoding_on_save 才管保存
default_encoding 在 ST4 中已被弃用，它只影响新建文件右下角显示和另存为对话框默认项，不控制 Ctrl+S 真实落盘行为。真正起作用的是 default_encoding_on_save。
- 同步配置若只写了
"default_encoding": "UTF-8"，但没写default_encoding_on_save，那你在 Mac 上保存的文件，在 Windows 上双击打开时仍可能被 fallback_encoding 错误解码 - 必须显式加这行：
"default_encoding_on_save": "UTF-8"（大小写、短横严格匹配） - 如果团队强制要求 BOM（极少数 Windows 工具），写成
"UTF-8 with BOM"；否则务必加"save_with_bom": false，否则 Python/Git 会报Non-UTF-8 code starting with '\xef'
同步配置含中文路径或注释，Linux/macOS 机器一打开就乱？别碰 detect_indentation
中文注释本身不会导致格式错乱，但若同步配置里混用了 Tab/Space 缩进，而 detect_indentation 被设为 true，Sublime 会根据文件首行缩进自动覆盖你写的 tab_size 或 translate_tabs_to_spaces，造成 JSON 格式意外损坏。
- 检查同步来的
Preferences.sublime-settings，确保没有"detect_indentation": true—— 这个选项对配置文件本身毫无意义，反而容易把整齐的缩进搞崩 - 所有缩进相关设置（
tab_size、translate_tabs_to_spaces）应显式写出，不要依赖自动探测 - 如果配置里有中文路径（如
"font_face": "微软雅黑"），确认目标机器真装了该字体；否则直接删掉整行，用系统默认字体更稳
最易被忽略的一点：同步工具（如 Git、Dropbox）本身不校验编码一致性。一份在 Windows 上用 GBK 保存的配置文件，拉到 macOS 上，Sublime 仍会按 fallback_encoding 规则去读——哪怕你配置里写着 "UTF-8"，只要字节流本身是 GBK，它照样崩。所以同步前，先用 file -i Preferences.sublime-settings 确认真实编码，再统一转成 UTF-8 无 BOM。
