根本原因是构建系统未对齐编码：必须用"cmd"模式、显式Python路径、加-u参数，并设"encoding": "utf-8"；改完需手动切换构建系统生效。
Sublime 运行 Python 脚本时控制台输出中文变问号或方块，根本不是文件编码问题，而是构建系统没对齐 Python 子进程的 stdout 编码和 Sublime 控制台的解码逻辑——encoding 字段必须显式设为 "utf-8"，且必须用 cmd 模式调用真实 Python 可执行路径。
Python 构建系统必须加 "encoding": "utf-8" 且禁用 shell 模式
Sublime 的原生构建系统默认不指定 encoding，会退回到 Windows 系统 locale（通常是 GBK），而 Python 3 默认以 UTF-8 输出字节流，两者错位直接导致乱码。关键点：
-
"shell_cmd"写法（如"shell_cmd": "python -u $file"）完全忽略encoding字段，无效 - 必须用
"cmd"模式，并显式写入 Python 绝对路径（如"D:/Python39/python.exe"），避免环境变量间接调用带来的不确定性 -
"encoding": "utf-8"是唯一生效的编码声明字段，写成"UTF-8"或"utf8"都不行 - 务必加
-u参数：禁用 stdout/stderr 缓冲，否则中文可能卡住不输出
别信 chcp 65001 或 PYTHONIOENCODING 环境变量
这些在 Sublime 构建系统里基本不起作用：
-
chcp 65001只影响手动打开的 cmd 窗口，Sublime 启动的子进程不继承该设置 -
"env": {"PYTHONIOENCODING": "utf-8"}在 Windows 上对 subprocess 无效（Python 官方已确认） -
PYTHONUTF8=1在部分新版本 Python 中有效，但兼容性差，不能作为主力方案 - 真正起作用的只有三样：
cmd数组、-u、"encoding": "utf-8"
脚本开头加 # -*- coding: utf-8 -*- 不解决控制台乱码
这个声明只告诉 Python 解释器“怎么读我的源码”，跟 print() 输出到控制台的编码完全无关。但它仍有价值：
- 确保含中文字符串的源文件被正确加载（尤其在老项目混用多种编码时）
- 虽非必需，但显式声明可避免某些编辑器误判，建议保留
- 真正决定输出编码的是 Python 进程启动时的 I/O 配置，即构建系统里的
encoding和-u - 验证是否生效：写个
test.py，内容为import sys; print(sys.stdout.encoding)，输出必须是utf-8才算对齐
Mac/Linux 用户也得配 "encoding": "utf-8"
别以为只有 Windows 有这问题。虽然多数 macOS/Linux 终端默认 locale 是 UTF-8，但一旦终端设为 en_US.ISO-8859-1 或其他非 UTF-8 locale，同样会乱码。而且：
- Sublime 不读取终端 locale，它只看构建系统配置
- 跨平台协作时，统一写死
"encoding": "utf-8"是最稳做法 - 不依赖系统设置，意味着换机器、换用户都不用重调
- 如果用了
shell_cmd，哪怕 locale 是 UTF-8，Sublime 仍可能解析失败
最容易被忽略的是：改完 .sublime-build 文件后，必须手动切换一次构建系统（Tools → Build System → 选回你刚建的那个），否则 Sublime 不会重新加载配置。很多人改完保存就跑，结果还是乱码——不是配置没写对，是 Sublime 根本没读它。
