必须同时配置“cmd”数组调用、-u参数、“encoding”: “utf-8”及“env”: {“pythonioencoding”: “utf-8”, “pythonutf8”: “1”}，缺一不可；仅加源文件编码声明无效，因该声明只影响源码读取，不改变stdout字节流编码。
Sublime 编译报错信息乱码，不是文件编码错了，而是 Python 进程输出的字节流和 Sublime 控制台解码逻辑没对齐——必须同时配齐 -u、PYTHONIOENCODING=utf-8 和 encoding: "utf-8" 三项，缺一不可。
为什么加了 # -*- coding: utf-8 -*- 还是乱码
这行只告诉 Python 解释器“怎么读源码”，跟 print() 或报错时往 stdout 写什么字节完全无关。Windows 下默认用 cp936（即 GBK）编码输出错误信息，而 Sublime 控制台默认按 UTF-8 解码，字节对不上就变成 \xe4\xbd\xa0\xe5\xa5\xbd 或方块。
-
sys.stdout.encoding在 Sublime 构建中常是cp936，不是utf-8 - 即使文件保存为 UTF-8、也加了编码声明，
raise ValueError("参数错误")发出的仍是 GBK 字节 - 只改构建系统的
"encoding": "utf-8"字段，不生效；只加"env"也不够
PythonUTF8.sublime-build 必须配全的三个字段
新建一个构建系统（Tools → Build System → New Build System），粘贴以下内容并保存为 PythonUTF8.sublime-build：
{
"cmd": ["python", "-u", "$file"],
"selector": "source.python",
"encoding": "utf-8",
"env": {
"PYTHONIOENCODING": "utf-8",
"PYTHONUTF8": "1"
}
}
-
"cmd": ["python", "-u", "$file"]：强制启用无缓冲模式，避免 -u 缺失导致编码判断被缓存干扰 -
"env"中必须同时设PYTHONIOENCODING和PYTHONUTF8；只写前者在某些 Python 3.7+ 版本下仍可能 fallback 到 locale -
"encoding": "utf-8"是 Sublime 自己用来解码控制台字节流的，不是 Python 的输出编码 - 别用
["cmd", "/c", "chcp 65001 && python -u $file"]：Sublime 不走 cmd 的代码页逻辑，反而更乱
验证是否真生效，别靠肉眼
肉眼看中文显示正常 ≠ 底层编码对了——有些终端会做兼容性 fallback，看着对，其实还是 GBK 字节。唯一可靠方式是：
- 在终端里运行
python -c "raise ValueError('测试')"，复制报错行，粘贴到在线 hex 查看器（如 cyberchef），确认是否含\xef\xbb\xbf或纯 ASCII + 中文 UTF-8 字节 - 在 Sublime 控制台里右键 →
Copy报错内容，用xxd或 Notepad++ 查看真实字节（Windows 用户可用certutil -encodehex -f） - 如果
File → Save with Encoding → UTF-8后再运行还乱码，说明构建系统配置根本没加载——检查是否选中了刚建的PythonUTF8构建系统（右下角或Tools → Build System）
最容易被忽略的是：构建系统改完后没手动切换激活，或者 env 对象漏了逗号导致 JSON 解析失败，整个配置静默失效。建议保存后立刻用 print(repr(sys.stdout.buffer.raw.write(b'\xe4\xbd\xa0'))) 测试原始字节输出是否被正确识别为 UTF-8。
