你的终端里那个「无聊的字体」，是从代码里编译出来的

目录

• 等宽字体：程序员每天看八小时，却没人谈论的界面
• 打字机的遗产：为什么 0 和 O 必须长得不一样
• 一个「字体编译器」：把 9000 个字形，变成 146 个参数
• 我在服务器上，把 Iosevka 拆开数了一遍
• 同一个引擎的下一站：给中文世界造字体
• 字体是给代码看的，而这一次，字体本身是代码

---

等宽字体：程序员每天看八小时，却没人谈论的界面

每天打开编辑器，你面前是一行行字母。它们长得像打字机时代的东西：每个字符占一样宽，整整齐齐，像士兵列队。

你大概从来没想过这个队列本身是被「设计」出来的。

2026 年 10 月中旬，一个叫 Iosevka 的开源字体项目登上了 Hacker News 首页，606 分。这个项目在 GitHub 上有 22,977 颗星，从 2015 年发布到现在，十年里迭代了 34 个大版本——对常逛技术社区的人来说，每隔一阵就会见到它的名字。

Iosevka 有什么特别的？它是一款等宽字体——和系统里随便哪个等宽字体一样，每个字符占相同的宽度。

但它有一个和所有字体都不同的地方：它不完全是「画」出来的，是「写」出来的。 每一个字形，都是一段代码跑出来的结果。字体本身，是从一个编译器里编译出来的产物。

这个反过来的流程，用了十一年，长出了一整个字体家族：Monospace、Term、Fixed、Slab、Aile、Etoile……覆盖 248 种语言，7,735 个字符，GitHub 上 22,977 颗星。

打字机的遗产：为什么 0 和 O 必须长得不一样

先把时间拨回等宽字体的起点。

1860 年代，打字机量产。机械结构决定了每个键按下去，纸张前进的距离是一样的——不是设计选择，是物理限制。等宽是打字机的「不得已」，却成了之后一百年代码排版的标准：因为程序里，缩进、对齐、表格全依赖「列」的概念，而列需要每个字符一样宽。

但等宽有个代价：字符越窄，越容易混淆。

1 和 l，0 和 O，2 和 z——在衬线字体里，它们靠细节区分；在等宽字体里，如果所有字符都挤在同一个格子里，这些细节要么牺牲可读性，要么牺牲宽度。

传统的解决方法是妥协：把字体做宽一点，让每个字符都有足够的空间区分细节。代价是空间——同样屏幕宽度，能放的代码更少。程序员们早就习惯了这种「宽体」：DejaVu Sans Mono、Consolas、JetBrains Mono，一脉相承。

Iosevka 走的是另一条路：与其让设计师在「窄」和「清晰」之间二选一，不如把整个字形系统重写一遍。

一个「字体编译器」：把 9000 个字形，变成 146 个参数

Iosevka 的作者是 Belleve Invis，一位中国开发者。项目的标志性设计藏在介绍里：Versatile typeface for code, from code——「为代码而生的多面手字体，从代码里长出来」。

它不是一个字体，而是一套字体生成系统。字形不是用手绘出来的，而是用代码描述的：每个字母由一组几何参数定义（骨架、衬线、斜切、圆角），然后由一个构建引擎批量「编译」成最终字体文件。

这意味着什么？意味着字体设计的每个环节，都变成了可配置的开关。

官网列出的定制项：146 个可配置字符——从「1 的顶部要不要横杠」「a 是单层还是双层」「0 要不要带斜线」「f 的横杠要不要突出」到「括号的弧度」——每个都对应一个样式变体。加上 19 个 stylistic sets（风格集），你可以像拼积木一样组装自己的字体：要编程连字（!=、=>、=== 自动连成箭头）？打开 liga 开关。要旧式数字？打开 onum。要让 l 和 1 分得清清楚楚？切到 SS01。

这种「字体即代码」的哲学，在打造 Iosevka 时处处可见：它有个听起来很离谱的特质——空间效率。常规等宽字体的字宽是 0.6 em 左右，Iosevka 的字宽只有 0.5 em。同样一段代码，它比 DejaVu Sans Mono 窄 17%。

「窄了不会糊吗？」这是每个第一次见到 Iosevka 的人都会问的问题。答案藏在字形设计里：它在极窄的宽度里，靠「锐利」的笔画形状和刻意的细节，让 1 和 l、0 和 O、2 和 z 依然分得清。它不是把字体压扁，是把字形重新设计了一遍。

我在服务器上，把 Iosevka 拆开数了一遍

写文章前，我从 GitHub 拉了一个 Iosevka 的 TTF 文件下来，在服务器上用字体解析工具把它拆开，逐项数了一遍。

字符量： 单个字体文件里装了 7,735 个 Unicode 字符（对应 9,060 个字形）。作为对比，系统自带的 DejaVu Sans Mono 是 3,322 个字符——Iosevka 是它的 2.3 倍。我逐个实测了几个区块：拉丁、希腊、西里尔、盲文、数学符号区（∀∑ 等）、罗马数字都在里面；官网标注的 248 种支持语言，主要由拉丁/西里尔/希腊扩展脚本构成。需要注意：Iosevka 本身不含 CJK/假名（那是更纱黑体干的活，后面会讲）——一款等宽字体把非拉丁脚本做到这个覆盖度，已经相当罕见。

等宽证明： 我随机取了 16 个字符（i l 1 m W @ # % & M 0 8），逐个测量它们的 advance width——全部是 500/1000 em，一个不多一个不少。等宽是所有等宽字体的共性（系统里的 DejaVu Sans Mono 也是严格统一，1233/2048 = 0.60 em），所以关键区别不在「严格」，在「多窄」：Iosevka 用 0.50 em 完成了 DejaVu 用 0.60 em 才做到的事——同样严格的对齐，窄了 17%。

空间账本： 同样一段 45 字符的代码，用 PIL 实际渲染：Iosevka 占 860px，DejaVu Sans Mono 占 1035px。换句话说，同样宽度的编辑器窗口，Iosevka 能多放约 14 个字符/行——在某些分屏场景里，这就是「代码看得完」和「要横向滚动」的区别。

连字： 有趣的是，我拉的这款 Fixed 版本连字数是 0——Iosevka 的连字是分版本的。你要 => 变箭头？请用默认版；你要绝对干净的纯等宽？用 Fixed 版。连字都不是「有或没有」，而是「可选项」。

这些数字拼起来，指向一件很朴素的事：Iosevka 的「窄」，不是偷工减料，是重新设计。 它的 0.5em 字宽是刻意的——为了在同样屏幕里放更多代码；它的 7,735 字符是刻意的——为了让任何语言的程序员都有的用；它的严格等宽是刻意的——因为「对齐」本身就是等宽字体的存在意义。

同一个引擎的下一站：给中文世界造字体

Iosevka 的项目简介里有个字眼：「from code」。这四个字不只在说 Iosevka 自己，也在说 Belleve 的整个创作路径。

他用的是同一套「字体即代码」的思路，在 2017 年启动了另一个项目：更纱黑体（Sarasa Gothic）——现在 GitHub 上 12,873 颗星。

更纱黑体解决的是中文程序员的一个老大难问题：中英文混排的对齐。等宽字体管住了 ASCII，但中文是全宽字符（1 em），英文是半宽（0.5 em），两边要精确对齐 2:1 的比例，几乎没有现成字体能做到。传统方案是「中文一套、英文一套、手动切换」，渲染时总差半个像素，表格和注释的对齐永远差口气。

更纱黑体把 Iosevka 的等宽字形和思源黑体（Adobe 与 Google 联合开发的中文开源字体）的中文合体：程序里 [1, 2, 3] 和注释里的「// 数组」，在同一个编辑器里，宽度比例严格 2:1，每一列都对得整整齐齐。

一个作者，两套字体，同一个引擎：一边是给全世界程序员的 0.5em 窄体，一边是给中文世界的 2:1 对齐。中文开源字体生态里，几乎没有第二个人同时做到这两件事。

字体是给代码看的，而这一次，字体本身是代码

Iosevka 官网的下载页，一行一行列着几十种形态：Monospace、Term、Fixed、Slab、Curly、Aile、Etoile……每种又有 Regular / Bold / Italic / Oblique，再乘以十几套样式变体，总资产 453 个发行包。这不是人工一个个「画」出来的，是同一个构建脚本跑出来的。

这个事实放在字体史里有点奇妙。过去一百年，字体是设计师用贝塞尔曲线一笔一笔描出来的艺术品；而在 Iosevka 里，字形变成了参数，字体变成了构建产物，设计变成了配置文件。它依然需要审美——146 个字符变体的默认值，就是 Belleve 的审美——但「调整审美」的成本，从「重画几百个字形」降到了「改一行配置，重新编译」。

程序员每天看八小时的字，终于由程序员自己的方法造出来了。

而这大概是它能持续十年、攒下两万多颗星的原因：他们每天用的东西，终于被一个懂他们的人，用他们熟悉的方式，重新造了一遍。

---

本文写作时的数据来源：Iosevka 官网（typeof.net/Iosevka，v34.9.0）、GitHub API（星数与许可证）、本地 fontTools + PIL 实证。Iosevka 与更纱黑体均以 OFL-1.1 许可开源。