因为 figlet 字体里没有汉字。 figlet 用的是 .flf 字体文件，这个格式诞生于 1991 年，收录范围基本就是 ASCII 加上部分 Latin-1，汉字、日文、emoji 的码点根本不在里面，渲染时会被直接跳过。这不是工具没做好，是 FIGfont 规范本身的边界。所以中文要切到「中文点阵」模式，走的是完全不同的一条路：先用系统字体把字画到画布上，再逐块采样成字符。页面检测到非 ASCII 字符时会直接弹提示，点一下就切过去了。

实心最保险，任何字号都认得出；灰度效果最好——它按笔画的浓淡映射成深浅不同的字符，抗锯齿的边缘天然带灰阶，出来最接近原字形，代价是字符种类多、粘到纯文本环境里有时会显得花；轮廓只画笔画的边，适合大字号，小字号下笔画本身就一格宽，画出来和实心没区别；反白是把背景填满、笔画留空，做成「墨底白字」的印章效果，行数调到 12 以上才看得清。

本机没装那款字体。 中文点阵是用系统字体把字画出来再采样的，所以能选什么取决于你电脑里装了什么：macOS 一般有苹方、宋体-简、楷体-简、圆体-简，Windows 一般有微软雅黑、宋体、楷体、仿宋，两边并不重合。工具在加载时逐款探测，没装的置灰而不是隐藏——藏起来的话，同一个页面在两台机器上选项数量不一样，反而让人以为是自己看花了眼。顺带一提，探测用的是拉丁字母样本：汉字在所有中文字体里都是全角等宽的，拿汉字去量宽度，任何字体都会被判成「没装」。

骨架完全不同。 黑体笔画等宽、转折方正，点阵化之后最清楚，字号小也认得出；宋体横细竖粗还带字脚（笔画末端的小三角），低分辨率下横画容易断掉，但字号一大就很有味道；楷体有提按和斜势，最像手写，也最挑行数；圆体端点是圆的，观感柔和；仿宋更瘦长，同样行数下占的列数少。一般建议：12 行以下用黑体，16 行以上再试宋体和楷体。

宽度是行数推出来的，不能单独设。 中文点阵按「1 个字符格 = 1 像素宽 × 2 像素高」采样——因为终端里一个字符本身就是高约为宽两倍的长方形，采样块不按 1:2 走，字会被压扁。所以选 10 行，渲染时字号就是 20 像素，三个汉字大约 60 像素宽，也就是 60 列。要压窄只能减行数。

80 列是终端和代码块的传统宽度。 这个数字来自打孔卡，一直沿用到今天：大多数终端默认 80 列，GitHub 的代码块在常见屏宽下也差不多是这个量级。超过之后会折行，而字符画一旦折行就彻底散架，看不出原来是什么字。工具在超过 80 列时会提示，英文模式可以换「紧凑」字间距或更小的字体，中文模式把行数调小。

因为它们的显示宽度不确定。 这几个字符在 Unicode 里属于「东亚宽度歧义」类：在西文环境下占一格，在中文、日文、韩文环境的终端里可能占两格。同一份字符画，在你的编辑器里是对齐的，同事的终端里就歪了。观感确实比 @ # * 好，但要粘进代码注释、README 或者要发给别人看的场合，用纯 ASCII 的那七个更稳。「方块」那组字符梯度同理。