根本原因是utf-8解码gbk字节流导致错乱，修复须先reopen with encoding→chinese (gbk)使内容可读，再save with encoding→utf-8转存；fallback_encoding必须设为"chinese (gbk)"，default_encoding已弃用。
Sublime Text 里符号索引（比如函数名、变量名、注释中的中文或特殊符号）显示为方块、问号、“锟斤拷”，不是字体没装好，也不是文件损坏——**根本原因是编辑器用 UTF-8 解码了实际为 GBK/GB2312 的字节流，解错位置导致后续所有字符偏移错乱**。修复必须从“读对”开始，而不是调字体或改 default_encoding。
怎么快速确认当前文件真实编码？
别信右下角状态栏显示的 UTF-8 或空白——它只是 Sublime 当前尝试的解码方式，不是文件真实编码。
Linux/macOS 下执行：
file -i 文件名看输出里的
charset= 字段（例如 charset=gbk）
Windows 用户直接用 Notepad++ 打开，右下角明确显示 GBK、UTF-8-BOM 等，比 Sublime 更可信
常见误判场景：detect_encoding: true 会跳过 BOM 强行试 GBK，把带 BOM 的 UTF-8 文件也判成乱码，建议删掉这一行配置
Reopen with Encoding 是唯一安全的救急操作
打开乱码文件后，立刻点击右下角编码标识 → Reopen with Encoding → 选 Chinese (GBK)（Windows 下常叫 CP936）
- 如果还是乱码，再试
Chinese (GB2312)或Western (Windows 1252)；只要中文一出来，右下角变成Chinese (GBK)，就说明原始编码识别对了 - 千万别点
Convert to UTF-8（老版本菜单里有）——它会静默重写文件且不提示，原始编码信息直接丢失 - 这个动作只影响当前视图内存内容，磁盘文件一字未动，完全可逆
Save with Encoding 才是真正转码动作
必须在 Reopen with Encoding 后中文显示完全正常，再执行：File → Save with Encoding → UTF-8（注意：不是 UTF-8 with BOM）
- 跳过上一步直接点它，等于把乱码再编码一遍，变成双乱码
- 保存后关闭再重开，右下角应显示
UTF-8，且中文依然正常；如果别人用记事本打开还是乱码，说明上一步没做对——文件根本没被正确识别为 GBK - 验证是否真去除了 BOM：
xxd 文件名 | head -n1
，输出不含ef bb bf才算干净
用户设置里 fallback_encoding 必须设为 "Chinese (GBK)"
fallback_encoding 字段不接受标准编码名，写 "UTF-8" 是无效配置。Sublime 只认自己内置的编码标识符，比如 "Chinese (GBK)"
-
default_encoding在 ST4 中已被官方标记为“已弃用”，它只影响新建空文件右下角显示的编码标识，不控制Ctrl+S的实际写入编码 -
fallback_encoding是“读取失败时尝试的备选编码”，比default_encoding更安全：它只在 UTF-8 解码失败时才启用 GBK，不会误伤真正的 UTF-8 文件 - 推荐组合：
"fallback_encoding": "Chinese (GBK)"+"save_with_bom": false，避免 Python/Git 报Non-UTF-8 code starting with '\xef'
seanliang/ConvertToUTF8（作者原 repo），下载 master 分支 zip，手动放入 Packages 目录。ST4 用户若发现兼容问题，可换用 Codecs36，但优先手动确认编码再决定是否依赖插件。
