Sublime Text控制台中文乱码是构建系统编码配置错误，需用cmd数组模式配"cmd"绝对路径、"-u"参数和严格大小写的"encoding": "utf-8"，并手动切换构建系统生效。
Sublime Text汉化后控制台（Build Results）中文乱码，和菜单/界面是否汉化完全无关——这是构建系统（.sublime-build）的编码配置错误，不是字体或语言包问题。改字体、装ConvertToUTF8、右下角切编码，全都不影响 Build Results 窗口里的 print() 输出。
为什么“汉化后乱码”是误导性归因？
菜单汉化失败导致的是顶部菜单栏显示□或英文，而控制台乱码来自 Python 子进程的 stdout 字节流解码失败。两者走的是完全不同的渲染链路：前者依赖 UI 字体与 locale，后者取决于构建系统中 "encoding" 字段是否生效、Python 是否以 UTF-8 模式启动。
- 汉化插件只修改
Packages/Default.sublime-package里的菜单资源文件，不碰构建逻辑 -
Build Results窗口内容由 Sublime 启动的 subprocess 产生，其 I/O 编码协商只看 .sublime-build 配置 - 即使你用繁体系统+日文字体+英文菜单，只要构建系统配对了
"encoding": "utf-8"和-u，print("你好")就能正常显示
必须用 cmd 数组模式，禁用 shell_cmd
shell_cmd 写法（如 "shell_cmd": "python -u $file"）会直接忽略 "encoding" 字段，Windows 下强制 fallback 到 cp936 解码，结果就是“浣犲ソ”或空格块。
- 只有一种模式能触发
"encoding": "utf-8"生效："cmd"数组 -
"cmd"必须写成绝对路径，例如"D:/Python311/python.exe"，不能写"python"（环境变量不可控） - 路径中反斜杠需转义为
"D:\Python311\python.exe"或统一用正斜杠"D:/Python311/python.exe" - 漏掉
-u参数会导致中文输出被缓冲，print()卡住不刷新，看起来像没执行
"encoding": "utf-8" 的大小写和位置必须严格匹配
这个字段名和值都区分大小写、带短横，且必须和 "cmd" 同级，不能嵌套在 "cmd" 里，也不能写成 "Encoding" 或 "output_encoding"。
- 正确：
"encoding": "utf-8" - 错误：
"Encoding": "UTF-8"、"encoding": "utf8"、"encoding": "UTF-8"、"encoding": "Utf-8" - 错误写法示例（字段放错位置）：
{ "cmd": ["python.exe", "-u", "$file", "encoding": "utf-8"] } - 验证是否生效最简方式：写个
test.py，内容为import sys; print(sys.stdout.encoding)，运行后输出必须是utf-8，否则说明配置未加载
改完必须手动切换构建系统，否则白配
保存 Python3.sublime-build 后，Sublime 不会自动启用它。很多人配完就 Ctrl+B，结果还是走默认 Python 构建系统，乱码照旧。
- 必须手动执行
Tools → Build System → Python3（名称要和你保存的文件名一致） - 确认右下角状态栏显示的构建系统名称已变为你刚命名的那个，比如
Python3 - 如果右下角仍显示
Automatic或Python，说明没选中，配置不会生效 - 脚本开头加
# -*- coding: utf-8 -*-对 Python 3 非必需，但建议保留——它能防止某些旧构建系统误判源码编码；更重要的是确保文件本身是 UTF-8 无 BOM 格式保存
真正麻烦的点不在写 JSON，而在于：每台 Windows 机器、每个 Python 版本都要单独填绝对路径；且每次改完 .sublime-build，都得记得去 Tools 菜单点一次切换——这个动作太容易被跳过，导致反复怀疑配置写错了。
