Sublime中文乱码绝大多数是编码错配所致，须先Reopen with Encoding选对原始编码（如Chinese (GBK)）使内容可读，再Save with Encoding→UTF-8转存；仅当编码正确仍显方块时才属字体问题。
字体安装后乱码，和字体本身无关，是 Sublime Text 仍在用错误编码解析文件 —— 换再好看的中文字体也显示不出“你好”，只会显示方块或“锟斤拷”。
先确认是不是真字体问题
乱码分两种：一种是字形缺失（显示为方块、空心矩形），一种是解码错误（显示为“烫烫烫”“锟斤拷”“”）。后者占九成以上，跟字体完全无关。
- 打开一个已知内容的纯中文文本（比如含“测试中文”的 .txt 文件）
- 右下角状态栏看当前编码名：
UTF-8、Western (ISO 8859-1)或空白？如果是这些，基本可断定是编码错，不是字体问题 - 点右下角编码名 → 选
Reopen with Encoding→Chinese (GBK)，如果中文立刻变正常，说明就是编码识别失败 - 只有在确认编码正确（状态栏显示
GBK或UTF-8且中文清晰）后仍显示方块，才需排查字体
字体配置必须配合 font_face 和 font_options
只装了微软雅黑或思源黑体，不改配置，Sublime Text 默认仍用 Consolas 或 Monaco 这类无中文支持的字体。
- 进
Preferences → Settings – User，在右侧面板 JSON 中添加： -
"font_face": "Microsoft YaHei, SimSun, sans-serif"（Windows） -
"font_face": "PingFang SC, Hiragino Sans GB, sans-serif"（macOS） -
"font_face": "Noto Sans CJK SC, WenQuanYi Zen Hei, sans-serif"（Linux） - Windows 用户建议加：
"font_options": ["directwrite"]，缓解模糊和小字号锯齿 - 改完保存，**必须重启 Sublime Text**，部分版本不重启不生效
ConvertToUTF8 插件和字体设置会互相掩盖问题
插件装完发现字体配置失效？大概率是插件触发了编码重载，把字体渲染上下文刷掉了。
- ConvertToUTF8 在 ST4 中默认不监听新文件加载事件，首次需手动
Reopen with Encoding才激活；这个过程可能重置视图渲染状态 - Codecs37 更稳定，但也会在自动识别编码后刷新视图——此时若
font_face里没包含系统已安装的中文字体名，就会回落到默认英文字体，造成“突然变方块” - 验证方式：打开一个 UTF-8 编码的中文文件 → 确认状态栏显示
UTF-8→ 此时再看是否还乱码；如果是，就纯属字体配置问题 - 别依赖
fallback_encoding来“兜底”字体显示——它只管解码，不管渲染
真正需要装字体的唯一场景
只有当编码正确（状态栏明确显示 GBK 或 UTF-8）、中文字符已解码为 Unicode、但依然显示为空心方块或小方点时，才该怀疑字体。
- Linux 用户注意：
fc-list :lang=zh查看系统是否真装了中文字体；很多发行版默认不带完整 CJK 字体包 - Windows 用户避免用“字体册”式安装（即双击 .ttf → 安装）；应复制到
C:\Windows\Fonts目录并重启资源管理器 - macOS 用户不要仅靠“字体册”预览，要勾选“安装到用户”并重启 Sublime Text
- Sublime Text 不支持 OpenType 可变字体（如
Noto Sans CJK VF），选静态版本
最常被忽略的一点：你看到的“乱码”，90% 发生在文件刚打开的前 200ms 内 —— 那是 Sublime 还没完成编码探测、也没应用字体配置的窗口期。别急着截图报 bug，等状态栏编码名稳定、字体名出现在右下角后再判断。
