控制台中文显示方块是字体缺失而非编码错误；Sublime按font_face顺序查找字形，全缺失时回退至系统默认字体（如SimSun）导致方块，删font_face重启后消失即可确认。
控制台输出中文变方块，不是编码问题而是字体缺失
方块（□）和问号、乱码字符是两类完全不同的问题：前者是 Sublime 找不到对应字形，后者才是 stdout 字节流解码错位。如果你的控制台里英文正常、中文全显示为方块，且右下角状态栏明确显示 UTF-8，基本可以排除构建系统配置错误，直接锁定字体回退失败。
Sublime 渲染中文时，会按 "font_face" 设置中声明的字体顺序逐个查找 glyph；一旦所有指定字体都不含该字符，就回退到系统默认字体（Windows 上常是 SimSun 或 MS Gothic），而这些字体在简体中文环境下常缺字或只支持繁体，结果就是方块。
- 临时验证方法：在 Preferences → Settings 右侧用户配置中删掉
"font_face"行，重启 Sublime —— 如果方块消失，说明原字体列表有问题 - 别指望靠改
default_encoding或fallback_encoding解决方块，它们只影响文件读取，不干预控制台渲染 - Mac/Linux 用户同样可能遇到，尤其当
font_face指向了不含 CJK 的编程字体（如 Fira Code、JetBrains Mono）时
怎么配 font_face 让控制台中文不显方块
关键不是“加一个中文字体”，而是让 Sublime 在查完主字体后，能顺滑回退到一个完整支持简体中文的字体。推荐用逗号分隔的 fallback 链，例如：
{
"font_face": "Fira Code, Microsoft YaHei, sans-serif",
"font_size": 12
}
注意点：
-
Microsoft YaHei（微软雅黑）在 Windows 上自带、字形全、渲染清晰；macOS 可换为"PingFang SC"，Linux 可用"Noto Sans CJK SC" - 不要只写一个中文字体（如
"SimSun"），它字重单一、等宽性差，容易导致对齐错乱 - 避免使用带空格或括号的字体名（如
"Source Code Pro"），某些版本 Sublime 会解析失败；稳妥写法是去掉空格或用引号包裹 - 改完设置必须重启 Sublime，字体变更不会热生效
为什么改了构建系统还是方块？先分清输出层和渲染层
很多人把 "encoding": "utf-8" 和 -u 参数配得严丝合缝，控制台仍出方块——这是因为这两项只管“Python 输出什么字节”和“Sublime 用什么编码解这些字节”，不管“解出来之后拿什么字体画出来”。这是两条独立链路：
- 构建系统负责：Python 进程 stdout → 字节流 → Sublime 按
encoding解成 Unicode 字符串 - UI 层负责：Unicode 字符串 → Sublime 渲染引擎 → 查
font_face→ 找 glyph → 绘制像素 - 所以即使
print("你好")正确输出、sys.stdout.encoding返回utf-8，只要字体链断在最后一环，照样方块
验证是否真解码成功：在脚本里加 import sys; print(repr(sys.stdout.encoding))，输出应为 'utf-8'；若不是，再回头调构建系统；若是，就只动字体。
Windows 下特别容易踩的坑：SimSun 和 NSimSun 的区别
很多用户写 "SimSun" 以为能解决方块，结果发现部分汉字（如“镕”“昇”）还是方块——因为 Windows 自带的 SimSun（宋体）实际是 GB2312 字集，缺大量扩展汉字；而 NSimSun（新宋体）才支持 GBK/GB18030，字形更全。
- 优先用
"NSimSun"替代"SimSun"，尤其处理政务、古籍、人名等含生僻字场景 - 但
NSimSun等宽性不如Microsoft YaHei，建议作为 fallback，而非主力字体 - 如果用了
"Microsoft YaHei"还有方块，检查是否开启了 ClearType 或显示器缩放比例异常（如 125%），有时会触发字体渲染降级
方块问题最麻烦的地方在于：它不报错、不警告，只静默失败。你得靠“删 font_face → 重启 → 看是否恢复”这种硬手段来交叉验证，不能只信状态栏或日志。
