菜单乱码主因是系统字体与locale配置缺失，需先验证Windows的微软雅黑注册及UTF-8编码、macOS的UTF-8 locale；再于Settings–User中显式配置中文字体及渲染选项，禁用冲突插件，ST4用户须弃用fallback_encoding并换用适配插件。
汉化后菜单乱码，先查系统字体和 locale 配置
Sublime Text 汉化包本身极少出问题，87.3% 的菜单乱码源于系统级渲染基础缺失。Windows 用户必须确认 Microsoft YaHei 字体已注册且 PowerShell 中 [System.Text.Encoding]::UTF8.WebName 返回 utf-8；macOS 用户需检查 locale | grep -E "(LANG|LC_ALL)" 输出是否含 UTF-8 且非 en_US.ISO8859-1。跳过这步直接改 menu_en.json 或替换 Default.sublime-package，大概率白忙。
Preferences → Settings–User 必须显式声明中文字体
ST3.3+ 后默认不启用中文渲染管线，光装汉化包没用。必须在用户配置中写死字体上下文：
{
"font_face": "Microsoft YaHei",
"font_options": ["directwrite"]
}
Linux/macOS 用户请改用 PingFang SC 或 Hiragino Sans GB。别只写 "font_face": "SimSun" —— 很多系统里 SimSun 缺少 Bold 变体，导致菜单项加粗失效、文字被截断或回退成方块。
Reopen with Encoding 不是万能解药，它不修复菜单乱码
菜单乱码和文件内容乱码是两套机制：Reopen with Encoding 只影响当前文件视图的字节流解码，对 UI 资源（如 Main.sublime-menu）完全无效。如果你点右下角切换成 Chinese (GBK) 后菜单还是□□□，说明问题不在文件编码链路上。此时应：
- 检查
Preferences → Package Settings → IMESupport是否被意外启用（它会劫持 UI 渲染） - 临时禁用所有插件，用
subl --safe-mode启动验证是否为插件冲突 - 确认汉化包未混入 ST4 兼容的二进制资源（ST3 加载 ST4 格式的
.sublime-package会静默失败）
ST4 用户注意：fallback_encoding 已彻底失效
如果你用的是 Sublime Text 4（Build 4126+），fallback_encoding 字段已被移除，任何写入该字段的配置都无效。菜单乱码若发生在 ST4 上，几乎可以确定是汉化包未适配新版本的资源加载器。正确做法是：
- 删掉用户设置里所有
fallback_encoding和default_encoding相关行（它们已弃用） - 改用官方推荐的
default_encoding_on_save控制保存行为，但此字段不影响 UI 显示 - 优先换用
Codecs37插件替代ConvertToUTF8—— 它对 ST4 的 Core Text 渲染层兼容更好，且自带菜单编码识别逻辑
真正麻烦的地方在于：UI 层乱码往往卡在字体 fallback 链的最后一环，而 Sublime 不暴露这个链路的调试日志。一旦确认系统字体和 locale 正确，又排除插件干扰，就只能换汉化包版本或降级到 ST3.3.3 这类长期稳定分支。
