sublime构建系统需用"cmd"数组模式并配置"encoding":"utf-8"才能正确解码utf-8输出；"shell_cmd"模式下该字段无效，python须加-u参数，路径须为绝对路径且反斜杠需转义或改用正斜杠。
Sublime 构建系统要让控制台正确显示 UTF-8 输出（比如 Python 的 print("中文") 或 C++ 编译错误里的中文），关键不是改编辑器文件编码，而是让 Sublime 在读取子进程 stdout 字节流时，用 UTF-8 去解码——这只能靠 .sublime-build 文件里显式配置生效。
为什么 shell_cmd 写法一定失败
很多人写 "shell_cmd": "python -u $file"，再加 "encoding": "utf-8"，结果完全没用。因为 Sublime 在 shell_cmd 模式下压根不读 encoding 字段，直接退回到系统 locale（Windows 上通常是 cp936）去 decode 字节流。Python 3 默认输出 UTF-8 字节，GBK 解码器一碰就崩，显示成 涓枃 或方块。
-
shell_cmd是壳命令，Sublime 不解析其 encoding，只用于简单调用 - 必须改用
"cmd"数组模式，这是唯一能触发encoding字段的路径 - 数组里不能写
"python"，得是绝对路径，比如"D:/Python39/python.exe" - 漏掉
-u参数会导致 print 中文被缓冲卡住，不立即输出
encoding 字段的大小写和拼写极其敏感
这个字段名和值都严格校验，错一个字符就失效：
- 字段名必须是
"encoding"，写成"Encoding"、"output_encoding"都无效 - 值必须是
"utf-8"（全小写、带短横），"UTF-8"、"utf8"、"Utf-8"全部不认 - 它只在
"cmd"模式下起作用，且仅影响 Sublime 对子进程 stdout 字节流的解码行为 - Mac/Linux 用户也得配——只要终端 locale 不是 UTF-8（比如
LANG=en_US.ISO-8859-1），照样乱码
Python 和 C++ 构建系统的配置差异
虽然都要用 "cmd" + "encoding": "utf-8"，但具体参数差异很大：
- Python：必须带
-u参数，路径用绝对路径，例如["D:/Python39/python.exe", "-u", "$file"] - C++（如 MinGW）：g++ 必须加
-finput-charset=UTF-8和-fexec-charset=UTF-8，否则字符串字面量在内存里就是错的；同时程序运行时还得自己调用SetConsoleOutputCP(CP_UTF8)才能让std::cout正常输出 - 正则匹配
file_regex要按实际编译器输出格式写，MinGW 错误行是main.cpp:12:5: error:，不能照搬 Linux GCC 的正则 - Windows 下别信
chcp 65001或"env": {"PYTHONIOENCODING": "utf-8"}——前者只改当前 cmd 窗口，后者在 Windows 上被 Python 官方标记为无效
改完构建系统后必须手动切换才生效
这是最容易被忽略的操作：保存 Python3.sublime-build 后，Sublime 不会自动启用它。
- 必须手动执行 Tools → Build System → Python3
- 如果路径含反斜杠（如
"D:\Python39\python.exe"），没转义就会报错，建议统一用正斜杠"D:/Python39/python.exe" - 验证是否真正生效：写个
test.py，内容为import sys; print(sys.stdout.encoding)，运行后输出必须是utf-8才算对齐 - 如果还是
cp936或mbcs，常见原因是构建系统没选中、路径写错、或 Sublime 启动失败后 fallback 到默认系统
真正难的不是写对那一行 "encoding": "utf-8"，而是意识到它只在 "cmd" 模式下起效、只管解码、不解决子进程内部编码问题——Python 要 -u，C++ 要编译参数加运行时 API，缺一不可。
