一个字号，只配一个行高

我维护一个中文 Web 平台的设计系统，页面大致分两类：列表、详情、长文这类浏览页，以及表单、查询这类操作页。设计系统里预设的一组字号与行高规格称为字阶，共有 16 档，按用途分成展示、标题、正文、辅助、控件、数据 6 组，每组各定各的行高。起初只想拿它和一个主流开源组件库的字阶比一比，看有没有能改的地方。统计、对照和批量修改都用脚本通过 Figma 的插件接口直接读写设计文件。

同一个字号有两个行高：14 号在正文组是 14/24，在控件组是 14/22；16 号是 16/28 和 16/24（16/28 指字号 16px、行高 28px）。只看表格是两个数，放进同一行就会错位：输入框用正文档，按钮用控件档，两者共用一套内边距，而文字中线的位置等于上内边距加上行高的一半。行高多 4px，控件就高 4px，文字也往下沉 2px。结果在 16 号这一对里，输入框比按钮高 4px、中线差 2px；14 号差 2px 和 1px。设计稿里这种错位常被手工微调盖住，到了开发阶段又换个样子出现。

按用途分组的语义化命名贴近业务、取用直观，起初被看作现有方案的长处。拿对不齐的输入框和按钮来检验就会发现，同一段 14 号文字归正文还是归控件，已经不只是叫法问题，它会实际改变布局；设计师取用前需要先想清楚这行字旁边站着谁，语义命名带来的不是方便，而是多一道选择。

重构方向列了三条：不再按用途命名；一个字号只对应一个行高；评估要不要加 13、15 号。评估第三条时，12 到 14、14 到 16 的级差已经只有 14% 到 17%，再插一档只剩 7% 到 8%，肉眼分不出，只会多一个「该选哪个」；想要的更紧凑其实是密度问题，应靠内边距解决；对照的开源组件库里，表格的三档密度用的是同一个字号，只有单元格内边距不同。最后前两条采纳，第三条否掉。12 到 20 号统一行高，14 号改成 22，16 号改成 24，其余不变；24 号以上的标题、展示、数据档各占一个字号，不和控件并排，不受这条约束。命名改成纯数字，比如 16/Medium，名字就是规格；前提是我确认过这个平台不会做大字号模式，否则写死在名字里的数字会在切换模式时失真。统一之后，三对样式变得逐字段相同（比如「按钮 16」和「正文强调 16」都是 16/24/Medium），按钮不需要专属字号档，三个重复档直接删掉。

详情页的长文用 1.75 的宽松行高读起来舒服，这是真需求，不能为了规则一刀切。起初只打算留 16 号一档，后来补上 14 号，保留了两个段落档 14/Paragraph（14/24）和 16/Paragraph（16/28）；名字里带 Paragraph，说明里写死只用于成段正文，不许和控件同行。

为了看整套字阶的行高顺不顺，引入了比例，即行高除以字号，代表每 1px 字号配了多少行距。这个比例应随字号增大而单调下降：读完一行，眼睛要回到下一行行首，字号小时一行字多、回扫距离远，需要更宽的相对行距引导；字号大时一行没几个字，同样的比例就显得松。把重构前、一个字号一个行高、单调化之后三个阶段画在一张图上，改变了问题的优先级。之前的文字讨论一直盯着 24 号的凸起，它比相邻档高 0.017；画出来才发现，重构前的曲线在 12 到 16 段往上走，14 和 16 两档高出趋势 0.25 到 0.30，是全场最大的偏离，比 24 号严重一个数量级。这也解释了对齐问题为什么恰好出在 14 和 16 号：只有这两档远离曲线。第一步统一行高已经把前半段拉回曲线；剩下的问题在后半段：24 号凸起，30 号和 20 号比例持平，字号大了 10px，比例却一样。

24 号的行高要在 32 和 34 之间定。按惯例定 32，理由有三条：这一档实测全是单行，行高只影响布局整不整齐，不影响阅读；32 在 4px 网格上；和对照的开源组件库同档一致。但只改 24 会把凸起变成凹陷：30 号的 1.400 本身偏高，24 降下去之后反而成了比两侧都低的点。曲线上的问题要整条看，不能逐点修。最后 24、30、36、48 一起调，改完后比例一路往下走，不再回头。28 号和 40 号两个数据档故意走更紧的行高：大数字永远是单行，不承担阅读引导，不放进这条曲线。新增或调整档位时，先把新值放进这条曲线看一眼：比两侧都高或都低的点，就是定错了的点。

段落档建好后，要把真正的长文迁过去，最初按文字行数大于等于 2 自动挑候选，挑出 108 个。但输入框里也能输入多行，算不算段落？复查发现，两行的 74 个绝大多数是卡片描述和页脚说明，不是长文。会不会换行只是形态，判据随之改成看容器的角色，即是不是一块能独立阅读的成段正文；控件里的文字不管几行都走默认档。最后真正迁进段落档的只有 7 处。抽象的规则要用具体场景检验：对不齐的输入框、能输入多行的文本框，都推翻过一次判断。

复核时发现，初判的 12 个段落候选里，有 5 个在已归档、不再使用的区域。原因是排除归档区的过滤只往上查了 3 层父级，而归档区在第 5 层。过滤改成一路查到页面顶层，才剔干净。

扫描全部 12 号文字时没有发现加粗用法，于是有了不必新增 12 号 Medium 的建议。我坚持要建，后来在「本期累计反馈 186 条」这样的句子里找到了真实用例：数字加粗，其余常规。这种段内混排，按整段扫描是看不见的。

写在文档里的规则迟早有人忘。为了把规则锁死，字号、行高、字重、字体族全做成 Figma 的设计变量（可以绑定到样式属性上的参数），行高变量按字号成对命名：font/size/14 对应的只有一个 font/lineHeight/14；段落档的变量名字里带 paragraph。这样在变量面板里，14 号只有一个同名的行高可选，没有选错的余地；要用段落档，必须主动去挑名字里带 paragraph 的那个。一共 28 个变量，16 个样式各绑字体族、字重、字号、行高 4 个字段，共 64 处绑定；绑完后回读全部样式，显示值没有任何变化：只改了数字的来源，没改数字本身。

合并重复样式时，组件实例上有本地覆写（实例上单独保留的样式设定），主组件改好了，100 处实例还按着旧样式不跟。脚本改为直接修改实例里的节点。

绑定字体族变量会让所有引用它的文字重新解析字体，其间有一个符号回退字体（文案里的符号落在这个字体上）没加载，导致整批绑定失败。脚本从报错里读出字体名，补加载后重试。

定下来的规则是：12 到 20 号，行高由字号唯一决定，用途只影响字重；24 号以上各占一个字号；只有两个 Paragraph 档例外，控件里的多行输入也不算段落。样式数仍是 16 个：删了 3 个重复档，加了 12 号 Medium 和两个段落档。约 3200 处文字自动跟着更新；受影响的 2643 个图层里，2620 个在自动布局（Figma 里能随内容自动调整尺寸和排布的容器）内、自己回流到位，占 99.1%；1 处固定高度的对话气泡要手工修；没有一处被截断。规范板也改成由同一份数据生成，参数列从样式里读取，不再手填。设计稿平时就用自动布局搭，这样改字号行高时，图层能自己回流。

最终字阶（字号 / 行高 · 比例 · 用途）

12/Regular · Medium

12 / 20 · 1.667 · 辅助信息、状态标签

14/Regular · Medium

14 / 22 · 1.571 · 列表、表格、表单、按钮

14/Paragraph

14 / 24 · 1.714 · 例外：长文段落

16/Regular · Medium

16 / 24 · 1.500 · 单行正文、卡片标题、大按钮

16/Paragraph

16 / 28 · 1.750 · 例外：长文段落

18/Medium

18 / 26 · 1.444 · 小标题

20/Medium

20 / 28 · 1.400 · 卡片标题、表内数值

24/Medium

24 / 32 · 1.333 · 区块标题

28/Bold

28 / 36 · 1.286 · 数据档

30/Medium

30 / 40 · 1.333 · 栏目标题

36/Bold

36 / 46 · 1.278 · 页面主标题

40/Bold

40 / 48 · 1.200 · 数据档

48/Bold

48 / 60 · 1.250 · 首屏大标题

改动结果

样式数量

16 → 16（删 3 个重复档，增 12 号 Medium 与两个段落档）

自动更新的文字图层

约 3200 处

风险扫描

2643 个受影响图层中 2620 个自动回流（99.1%）· 1 处手工修正 · 0 处截断

设计变量

28 个 · 64 处绑定 · 显示值零变化

结论

12–20 号的行高只由字号决定，行高 ÷ 字号的比例随字号单调下降；约 3200 处文字自动跟随；受影响的 2643 个图层里，99.1% 自己回流到位。

参数

14 → 22 · 16 → 24 · 24 → 32 · 段落档 14/24、16/28 · 28 个变量 · 64 处绑定

没做完

样式名里写死了数字，前提是平台不做大字号模式；真要做，命名得重来。

2026-10

首次记录