Sublime Text 菜单乱码主因是字体配置缺失或错误，需按系统指定中文字体（如 Windows 用 "Microsoft YaHei"）、显式配置 font_face，且汉化包须用 SublimeText-Localization 替换完整 Default.sublime-package。
菜单显示英文或一堆方块、□、，不是汉化包坏了，而是 Sublime Text 没法把中文字符画出来——核心卡在字体 + 编码渲染链路断了。
Sublime Text 菜单/界面乱码，先看系统有没有中文字体
界面文字（菜单、侧边栏、弹窗）走的是系统字体渲染管线，和你打开的文件编码无关。Windows 用户必须确认 Microsoft YaHei（微软雅黑）已安装且被 Sublime 识别到；macOS 用户要检查是否启用了 PingFang SC 或 Hiragino Sans GB；Linux 用户则需确保系统级 fontconfig 已加载 Noto Sans CJK 或 WenQuanYi Micro Hei。
- Windows：进控制面板 → 字体 → 搜索“Microsoft YaHei”，存在即合格；若无，从 Windows 系统盘提取或手动安装
- macOS：终端运行
locale | grep UTF，输出含UTF-8才安全；若为en_US.ISO8859-1，需改/etc/locale.conf或用defaults write -g AppleLocale "zh_CN" - Linux：执行
fc-list :lang=zh，至少返回一行中文字体路径，否则装fonts-wqy-microhei或noto-cjk
Preferences → Settings–User 必须显式声明 font_face
Sublime Text 不会自动 fallback 到中文字体，即使系统装了微软雅黑，不写配置它就用默认英文字体（如 Consolas），遇到中文直接回退成 或空白。这个字段不是可选项，是强制项。
- Windows 推荐写：
"font_face": "Microsoft YaHei"，别加逗号列表——多字体 fallback 在界面层不可靠 - macOS 写：
"font_face": "PingFang SC"或"Hiragino Sans GB"，避免混用中英字体名顺序 - Linux 写：
"font_face": "Noto Sans CJK SC"，注意后缀SC（简体）不能漏 - 切勿写成
"font_face": "SimSun, Microsoft YaHei"—— SimSun（宋体）在高分屏下渲染模糊，且 Sublime 对多字体解析不稳定
汉化包失效？先排除 ST3.3+ 的语言资源加载机制变化
ST3.3 之后，Default.sublime-package 改为只读 ZIP 包，且语言资源不再从 menu_en.json 动态加载，而是编译进二进制资源段。直接解压修改 JSON 文件、替换字符串，90% 情况下根本不会生效。
- 正确做法是用社区维护的 SublimeText-Localization 项目，按 README 替换整个
Default.sublime-package（不是解压后改单个文件） - 验证是否加载成功：启动后按
Ctrl+Shift+P输入Set Syntax: Plain Text，若菜单仍英文，说明语言包没加载；若变中文但字体糊，才是字体问题 - 别碰
Packages/ChineseLocalizations这类第三方插件目录——它们只管编辑区语法高亮，不管菜单 UI 渲染
控制台（Build Results）中文乱码是另一条链路，别和界面乱码混治
菜单乱码和构建输出乱码完全无关。后者由 .sublime-build 文件里的 "encoding" 和 Python 子进程 I/O 共同决定，改 font_face 或重装汉化包对 Build Results 窗口毫无影响。
- 新建构建系统（
Tools → Build System → New Build System），内容必须含"encoding": "utf-8"（顶层键，非嵌套在cmd下） -
cmd必须用数组形式，例如："cmd": ["D:/Python39/python.exe", "-u", "$file"]，禁用缓冲才能实时刷出中文 - 保存后必须手动切换一次构建系统（
Tools → Build System → [你的名字]），否则配置静默无效 - 脚本文件本身得是 UTF-8 无 BOM，可用 Notepad++ 的“编码 → 转为 UTF-8 无签名”验证
真正麻烦的从来不是配哪行代码，而是搞清当前乱码发生在哪一层：是菜单 UI（字体+汉化包）、是文件内容（编码识别+fallback_encoding）、还是构建输出（子进程通信+encoding 声明）——三层链路互不干扰，修错一层，其他照旧乱。
