企业官网建设流程全解析

还在为font-size设为100px、文字看起来却只有几十像素而困惑？搞不懂字体高度到底由谁决定？这篇从字体排印基础开始，把font-size与字体height之间那点纠缠不清的关系彻底掰开揉碎，包含CSS、Canvas、SVG场景下的真实测量方法与避坑思路，看完能直接回到项目里复用。

2. 解析基础：font-size到底定义的是什么

先问一个看似幼稚的问题：font-size: 100px，你期望得到什么？

大多数人心里想的是“字体的高度=100px”，但渲染结果经常打脸——有的字体看着有100px高，有的字体才70px高，还有人字号已经60px了，但一行文字的实际占位高度却远超60px。

原因在于：font-size本质上不是“字体的视觉高度”，而是字体设计中的一个基准尺寸，真正的视觉高度由字体自身的度量（metrics）决定。不同的字体在同一个基准尺寸下，上下延伸、内部留白各不相同，导致最终渲染结果千差万别。

插一个历史背景帮助理解。font-size的源头可以追溯到活字印刷时代的em quad。在铅字排版中，一个em正好是一个大写字母M的宽度乘以高度方向上的某个固定尺寸——它代表的是“印字方块”的尺寸，不是笔画本身的高度。今天的CSS、Canvas，甚至SVG，都继承了这套逻辑：你设置的font-size，定义的是这个“方块”在垂直方向上的占据空间，而方块里字形到底画到哪里，字体设计师说了算。

所以记住第一条定律：font-size是一个参考坐标系，不是最终测量值。你设置100px，得到的通常是一个“设计高度约为100px的可见字形+若干不可见的内建边距”的和。

需要补充的是，这里的“设计高度”并非空穴来风。字体文件中的hhea表（Horizontal Header Table）和OS/2表记录了ascender、descender、lineGap等关键度量值。这些值经过USUnitsPerEm的归一化后，会直接映射到设置的字号上。这也是同一行里不同字体段落高度不一致的根源。

概念上讲，你的字号设置了100px，则该字体的1em就等于100px。em盒（em box）的高度就是100px。字形有可能比em盒高，也可能比em盒矮，具体取决于字体设计。

2.1 从活字印刷到数字字体：em与px的换算逻辑

旧时排版工人把一枚小小的铅字块塞进排版框里，字块的一个正交方向尺寸被称为em。一枚“10pt的活字”指的是字块的高度方向是10pt，而字母“x”的可见高度通常远小于10pt。这个“块”的概念延续到了数字化时代，变成了我们常说的em box、em square。

数字字体里的em square是一个假想的正方形，边长通常是1000个单位（PostScript标准）或2048个单位（TrueType标准）。字体文件里所有轮廓坐标都建立在这个正方形内。渲染时，浏览器或绘图引擎会把em square等比缩放到你设定的font-size。

举个例子：假设某字体的ascender为800单位，descender为-200单位，那么该字体的内部高度是1000单位（正好占满em square），但当字号设为80px时，这1000个单位会被缩放到80px，所以ascender对应的像素高度=(800/1000)*80=64px，descender的像素值=(-200/1000)*80=-16px。也就是说，即使两个字体在数字坐标系里的轮廓完全一致，只要字体文件里记录的ascender/descender不同，最终屏幕上占据的垂直空间就会不同。

理解这个缩放关系后，一个衍生结论就很清晰了：font-size相同时，字体的可见部分和不可见部分的比例完全取决于字体文件的度量值。Roboto和Noto Sans在同一字号下看起来高度不一致，正是因为它们的urez（units per em）相同但ascender/descender不同。

2.2 字体度量的四个关键基准线

要理解height与font-size的关系，必须认识字体的几个核心基准线。它们虽然看起来是排印术语，但它们直接决定你在界面上看到的视觉高度和占位高度。

• baseline（基线）：字母底部对齐的那条假想线，CSS中的vertical-align: baseline就是以此为准。所有水平文本都以此作为垂直定位的锚点。

• ascender（升部）：从基线向上延伸到升部顶端的距离。小写字母d、h、k的顶部通常到升部顶端。在字体文件中通常记录为一个正值，单位是em square内的单位。

• descender（降部）：从基线向下延伸到降部底端的距离。小写字母g、j、p的下端会伸到这个区域。在字体文件中通常记录为负值或绝对值，取决于实现。

• cap height（大写高度）：大写字母H的顶部到底部的距离。注意，cap height通常小于ascender。很多字体在cap height上方还有一段“留白”，用于容纳重音符号等组合记号。

• x-height（x高度）：小写字母x的高度。x-height大的字体在小字号下可读性更好，但相同font-size下看起来也会更“占地方”。

这五条基准线一起构成了字体的垂直度量体系。标题里问的“字体height”，实际上要分两种情况：一种是你关心的可见字形高度（视觉高度），另一种是排版引擎为这行文字分配的占位高度（行盒高度）。两者都受上述基准线的直接影响。

字体文件中还有一个常被忽略的字段叫lineGap（行间距建议值）。Windows下的很多字体lineGap为0，而一些Apple字体lineGap较大。这导致同一font-size下，用不同系统自带字体渲染出的行高差异巨大。后面讲到CSS时你会看到这个字段如何参与最终行盒高度的计算。

3. 字体高度如何被排版引擎计算：CSS、Canvas与SVG的差异

知道了基准线，下一个问题是：排版引擎到底用哪些度量值来算最终height？不同渲染环境（CSS、Canvas、SVG）的算法有差异，这也是很多人换了个技术栈就踩坑的原因。

3.1 CSS的content-area与line-height

CSS布局中，一个inline元素在垂直方向上占据的空间，实际上分为两层：content area（内容区）和line box（行盒）。font-size决定了content area的基准高度，而line-height决定了line box的最终高度。

具体公式是：

line box高度 = line-height设置的数值 content area高度 = 由字体度量计算出的内建高度，通常是(ascender + descender)经em缩放后的值

如果你的line-height没有显式设置，浏览器会使用字体文件自带的lineGap/ascender/descender计算一个默认值。

举个例子：font-size: 16px，假设字体A内建line-height是1.2，则默认line box高度约为19.2px。但content-area可能只有14px，剩余5px左右均匀分布在上半leading（行距）和下半leading中。

同一个span里，不同字体混排时，浏览器会取所有字体的content-area上限作为该行的content-area上限，取所有字体content-area下限作为整行下限。这就是为什么一行里夹了中文+英文+emoji，行高会突然变“胖”——每种字体贡献了不同的度量数据。

实线及布局场景中最常见的坑是行盒高度不等于可见字形高度。设置line-height: 1后，行盒高度恰好等于font-size，但字形可能高出行盒上边缘，也可能低于下边缘，视觉上和相邻元素重叠。这类问题后面会展开讲。

3.2 Canvas与SVG中的测量机制

Canvas和SVG里没有line-height这个概念，它们的测量主要依靠字体度量表和metrics API。

Canvas中，你通过ctx.font设置字号与字体族，然后调用measureText获取文本宽度。但特别提醒：文本宽度由measureText().width给出，文本高度并不由measureText().height直接可靠提供。历史版本中，measureText只可靠返回width、actualBoundingBoxAscent、actualBoundingBoxDescent、fontBoundingBoxAscent、fontBoundingBoxDescent等字段，其中actualBoundingBox表示实际像素边界，fontBoundingBox表示字体边界。

实际开发里，我很推荐用actualBoundingBoxAscent和actualBoundingBoxDescent来精确定位垂直位置，因为它们是所见即所得。要想把Canvas里一行文本垂直居中到某个region，你需要这样做：

const ctx = canvas.getContext('2d'); ctx.font = '60px sans-serif'; const metrics = ctx.measureText('Hello'); const visualAscent = metrics.actualBoundingBoxAscent; const visualDescent = metrics.actualBoundingBoxDescent; const baselineY = (regionTop + regionBottom) / 2 - (visualAscent - visualDescent) / 2; ctx.fillText('Hello', x, baselineY);

这段代码的关键点在于：baseline不一定是区域中心，而是先将整个可见字形区域的垂直中点对齐到区域中心，反推出baseline的y坐标。如果直接采用区域中心作为baseline，视觉上文字会偏上约几个像素。

SVG中处理text元素时，没有直接等价于CSS的line-height属性。你可以通过dy偏移来微调文本基线，或者用dominant-baseline来改变对齐基准线。测量SVG文本的精确高度，通常需要先获取到对应的DOM节点，然后调用getBBox()获得bounding box。但这个bounding box是文字实际的几何包围盒，并非CSS意义上的行盒，因此它更接近字形像素边界。

3.3 字体内建行高与line-gap参与计算的实例

我用一个具体例子说明line-gap的影响。假设字体A在OS/2表中的数值为：

• usWinAscent: 1200
• usWinDescent: 300
• sTypoLineGap: 0

那么当font-size为100px、unitsPerEm为1000时，CSS的默认行盒高度大约等于(1200 + 300) / 1000 * 100 = 150px，而且没有额外的行间距。但如果你换了一个内建lineGap为200的字体B，同样的字号下，默认行盒高度可能变成(1200 + 300 + 200) / 1000 * 100 = 170px。

这就是为什么同一套布局里，把font-family从其中一个换成另一个，整体间距会被“撑大”或“压扁”。特别是安卓与iOS的默认字体差异，调整起来特别明显。

如果你希望完全掌控排版高度，常见的做法是手动设置line-height，但要注意：line-height: 1并不等于行盒高度等于字体可见高度，它只是把行盒高度设成了与font-size相同。在项目里，很多人遇到垂直居中问题后把它当作“万能灵药”，结果文字被裁切或重叠，原因就在于此。

推荐指数很高的组合是：设置line-height: 1.2到1.4之间作为安全值，同时利用overflow: visible观察实际渲染效果。强行把line-height设为1会让文字行盒紧贴，但字体内部自带的行距不会消失，仍可能造成视觉拥挤。

4. 实操指南：如何精确测量字体height并用它掌控布局

这一节讲实际操作。无论你是在做网页、移动端、Canvas绘图还是SVG图形，测量字体height的本质都是先获取基线数据，再根据业务需求算出基线位置。

4.1 在浏览器中用JavaScript测量文本真实高度

拿到一个DOM元素，想知道“这段文字到底占了多高”，最直接的是读取element.offsetHeight或getBoundingClientRect().height。但你拿到的是行盒高度（多行则是多行行盒之和），这里面包含了行高带来的leading，并非纯字形高度。

如果只关心字形本身的可见高度，标准做法是借助Range API获取文本几何信息。原理是Range有一个getBoundingClientRect()方法，它会返回被选中文本的视觉盒。具体代码是这样：

function getTextVisualHeight(el) { const range = document.createRange(); range.selectNodeContents(el); const rect = range.getBoundingClientRect(); return rect.height; } const el = document.querySelector('.text'); console.log(getTextVisualHeight(el));

这个方法返回的是文本实际渲染出的像素高度，不管行盒多大，它都只反映可见文字的最上沿到最下沿。如果你在做字幕插件、富文本编辑器、海报生成器这类需要精确渲染位置的场景，这个API非常有用。

另一个方式是调用document.fonts.ready后再测量，否则webfont未加载完成时可能量出fallback字体的高度。在线上项目中，字体加载与测量时序会直接影响计算准确性。

async function measureWithFont() { await document.fonts.ready; const el = document.querySelector('.text'); const range = document.createRange(); range.selectNodeContents(el); const rect = range.getBoundingClientRect(); console.log(rect.height); }

4.2 一行公式：已知font-size，推算CSS行盒高度

如果你不想引入DOM操作，想直接“算”出行盒高度，可以使用下面的公式。它依赖字体文件的度量表数据，而非document对象，所以适合Node环境下做布局预估。

步骤是先通过opentype.js或fontkit加载字体文件，然后拿到单位值：

const opentype = require('opentype.js'); const font = opentype.loadSync('path/to/font.ttf'); const fontSize = 100; const emScale = fontSize / font.unitsPerEm; const ascent = font.ascender * emScale; const descent = font.descender * emScale; const lineGap = font.tables.hhea.lineGap * emScale; const lineHeight = ascent - descent + lineGap; // descender通常是负值

在浏览器端没有opentype.js的场合，也可以利用CSS本身来反推：构造一个仅包含目标文字的元素，设display: inline-block，再读取它的offsetHeight。但这个方法耦合了浏览器渲染规则，重复构造开销较大，不如度量表计算来得直接。

注意：同一款字体在不同操作系统上可能由不同字体引擎渲染，但度量表数值通常一致，所以这个计算方式有很强的可移植性。唯一要留意的是字体的tricky怪癖，个别字体会在特定字号下调整hinting，导致实际渲染与度量表之间有细微偏差。

4.3 Canvas场景下的精确垂直定位

Canvas里没有DOM元素可查，最实用的方案是结合actualBoundingBox*字段。除了前面提到的垂直居中写法，还有几个高频场景前后端都会用到：

场景一：把文字画在某个固定矩形框内，并且上下留白均匀

function drawTextCentered(ctx, text, rect, font) { ctx.font = font; const metrics = ctx.measureText(text); const ascent = metrics.actualBoundingBoxAscent; const descent = metrics.actualBoundingBoxDescent; const visualHeight = ascent + descent; const centerY = rect.top + (rect.height - visualHeight) / 2; const baseline = centerY + ascent; ctx.fillText(text, rect.left, baseline); }

场景二：多行文本，行间距完全可控

多行文本不能简单用fillText逐行画，否则行与行之间无法用line-height控制。建议先计算每一行的高度，手动给出行距：

function drawMultiline(ctx, lines, x, y, font, lineGap) { ctx.font = font; const metrics = ctx.measureText('M'); const lineHeight = metrics.actualBoundingBoxAscent + metrics.actualBoundingBoxDescent + lineGap; let baseline = y; lines.forEach((line) => { ctx.fillText(line, x, baseline); baseline += lineHeight; }); }

把actualBoundingBoxAscent和actualBoundingBoxDescent相加，得到的是该行字体实际可见高度，再叠加自定义行间距，比用固定字号乘以某个系数可靠得多。

4.4 SVG中设置text大小与垂直位置的坑

SVG的text元素与canvas不同，它保留了完整的文本布局能力，但默认的垂直对齐逻辑经常让人头疼。默认情况下，text元素以baseline对齐到指定的y坐标。如果你直接写：

<text x="20" y="100" font-size="32">Hello</text>

那么单词底部的基线会落在y=100处，而不是字的几何中心或顶部落在100附近。对初学者来说，这很容易造成文字看起来“悬空”。

几个常用方法：

• 设置dominant-baseline="middle"，让文本以x-height的中心位置对齐到y坐标。但这个对齐基准由字体引擎决定，不同字体效果不完全一致。
• 使用alignment-baseline="middle"配合dominant-baseline="middle"来达到视觉居中。
• 自己测量baseline偏移：先用getBBox()拿到文本几何盒，再根据盒高度与基线之间的差值手动调整dy。

实操中，如果有较多文本要精确排版，我更倾向于用foreignObject嵌入HTML，让CSS的排版能力来处理复杂布局，而SVG里的text只负责简单标注和图标类文字。两个技术栈结合使用，会比在SVG里死磕基线更高效。

5. 同一字号，不同字体高度为何天差地别？字体文件里的隐藏差异

如果你在项目里遇到过“文字突然变高/变矮”的现象，大概率不是bug，而是字体自身的度量表差异导致的。这一节把这些差异摆上台面，下次遇到心里有底。

5.1 度量表差异：Ascender与Descender的真实数值对比

下面列一组常见字体在unitsPerEm=1000时，ascender/descender/lineGap的参考值。因为字体文件版本可能变化，具体数值请以实际ttf/woff2为准，但量级与差异趋势是稳定的。

看到没有，同样是100px字号，Arial的总行盒高度约111.7px，而Noto Sans SC约148px，差距超过36px。这还只是行盒高度，如果line-height是默认值（浏览器约normal=1.2），差距会进一步放大。

如果你的设计稿里统一用font-size衡量一切，不关注字体族变化，跨字体替换时垂直布局会出现明显的“呼吸感”。在设计系统或组件库中，最佳实践是统一封装字体栈，并为不同字体栈单独定义line-height。

5.2 OS/2表与hhea表对渲染的影响

字体文件中的hhea表负责提供ascender、descender、lineGap，这些数据主要被CSS和浏览器使用。而OS/2表里的WinAscent/WinDescent，则常被Windows的GDI渲染器使用。两套数据不一致时，会出现“同一字体在Mac浏览器里行高很舒服，在Windows浏览器里就变得异常”的经典兼容性问题。

具体来说，浏览器对line-height: normal的计算，在Windows上可能会优先采用OS/2表的usWinAscent和usWinDescent，而在macOS上则采用hhea表。很多中文字体为了兼容性，刻意把WinAscent/WinDescent设置得很大，导致Windows下行盒极高，而Mac下相对收敛。

解决方案并不困难：不要依赖line-height: normal。你可以在CSS中明确指定line-height: 1.4或基于百分比的行高，让不同系统使用同一数值。效果上，虽然leading的分配方式仍可能略有不同，但整体行盒高度趋同。

第二套常用方案是使用@font-face的ascent-override、descent-override、line-gap-override等描述符，直接覆盖字体文件的默认度量。这在做web font降级时特别有用。比如你主字体是Open Sans，备选字体是Arial，希望两者行高一致，可以这样写：

@font-face { font-family: 'ArialOverride'; src: local('Arial'); ascent-override: 1069/1000; descent-override: 293/1000; line-gap-override: 0/1000; }

这里的数值要与主字体的度量保持一致，实际项目中需要先测量主字体真实度量，再对备选字体做覆盖。浏览器支持情况已经不错，但建议在目标环境做一轮回归。

5.3 中文字体与英文字体的height差异

中文字体与西文字体在度量设计上区别很大。绝大多数DTP字体把中文字体设计成方形字面，而西文字体的升降部、大小写高度比例各不相同。同样设置font-size: 100px，中文字体因为字身较大，可见高度往往更接近100px，而中文标点、中文引号的上下空隙也可能导致行盒被意外撑大。

举例：Noto Sans SC在100px下，可见字形实际高度可能在95~110px之间，而英文字体Roboto在100px时，可见字形高度约70~80px。混排一行中英文时，中文字体会把行盒上下顶出去，造成行高变化。

遇到中英混排需要精确对齐的场景，可以分别按“高度更大的字体”作为行盒计算依据，统一设定line-height后，把英文文本的line-height覆盖调低。也可以利用CSS的vertical-align: middle把英文小元素按视觉中心对齐，但要注意vertical-align的语义是按基线与x-height计算的，不是按视觉块中心计算，效果只能微调，不能根治。

6. 进阶应用：用font-size与height关系解决真实布局问题

理论说完了，下面直接进入实战。很多布局类的经典难题，归根到底就是在处理“font-size与height关系”之间的落差。

6.1 按钮文字垂直居中的正确姿势

先说结论：在按钮这类高度固定的元素里，不要用line-height等于height的死方法。按钮高度为Height，单行文字font-size: 16px，一般设置line-height: 1是安全的，但前提是按钮没有内部border和line-height异常。

正确过程分三步：

1. 先设一个合理的line-height。优先使用1.2~1.4范围内的值，而不是直接等于按钮高度。
2. 用内边距（padding）而不是行高来撑出按钮高度。
3. 保证按钮的display: inline-flex，配合align-items: center。

.btn { display: inline-flex; align-items: center; justify-content: center; padding: 8px 16px; font-size: 16px; line-height: 1.2; border-radius: 6px; border: 1px solid #ccc; }

按钮高度由padding+border+font-size产生的行盒共同决定。font-size对最终高度的影响是间接的：它会决定line-height与基线位置，进而影响整个inline-flex容器的内容高度。先用flex垂直居中，再用padding控制整体高度，可以得到最稳定的效果。

不要试图把line-height设置为按钮的固定高度值。一旦字号或字体改变，行高会显著偏移，文字要么偏高要么偏低，而且这种情况下修改内边距会反过来影响视觉。

6.2 图标与文字对齐的度量调整

图标与文字对齐常遇到“差两三个像素”的目测问题。原因就是文本的垂直中心与图标的垂直中心不是同一条线。

一般图标是正方形或宽高相等的矩形，视觉中心即几何中心。但文字部分，几何中心大约在baseline上方，大概要上移到ascender与x-height之间的某个位置。不同字体比例不同，所以不存在固定的对齐公式。

比较可靠的三种做法：

• 给图标设置margin-top，用具体像素微调。适合一次性项目，简单快速。
• 给文本元素包裹一层flex容器，用align-items: center，再对font-size做小数调整。值得注意的是，align-items: center对齐的是行盒而不是基线，因此不同字体下依旧会有偏差，但比直接按基线对齐要稳定。
• 用CSS的ex单位做偏移。字体排印中1ex通常等于x-height，对部分字体来说，这能让文本视觉中心更接近几何中心。但ex在中文环境下定位不稳，因为中文字体的x-height不一定有参考价值。

实操上，我偏爱给文本一个小的负margin-top，把视觉中心向上抬一点，然后再用flex的align-items: center兜底。这样整体上线条切得干净，跨字体偏差也在可接受范围内。

6.3 多行文本行高设置与裁剪问题

多行文本中，height与font-size的关系主要体现为行高设置不当导致的裁剪。

假设一个固定高度容器内有两行文本，容器高度为48px，font-size为16px。那么设置line-height: 1.5时，两行总高为48px，恰好放得下。但不同字体下，行盒顶部的字形装饰可能超出行盒上边缘，导致第一行字形被顶部裁切，或者最后一行被底部裁切。

一个比较实用的防裁切策略是给容器增加少量padding，并让文本的line-height略大于计算所需值。例如，两行文本需要的最小行高是1.4，那就设置1.45，再把容器height改为自适应或height+padding分担。

另外，多行文本省略号（text-overflow: ellipsis）是一个高度相关的场景。CSS规范中，多行省略需要借助-webkit-line-clamp，它依赖line-height与容器高度。很多人做多行截断时，不小心把line-height设置成auto，导致行盒计算不稳定，省略号一下子不出现了。常规做法是先给容器设定一个明确的line-height，再通过max-height进行两行截断。

7. 常见问题排查与实测记录

这部分记录一些真实项目里遇到的问题，省得你重复踩坑。

7.1 常见问题速查表

7.2 一个真实案例：跨字体替换导致的行高突变

一个后台管理系统，原设计使用Roboto，后来为了支持中文引入了思源黑体，并将font-family改为“Roboto, 'Noto Sans SC', sans-serif”。结果所有表格行高突然多出十几像素，整个页面布局被撑变形。

排查过程：先确认是否是真多行文本导致的，结果表格中的单元格都是单行。再用JS测量发现行盒高度从预期的32px变成了近50px。最终定位到Noto Sans SC的line-gap或WinAscent值偏高，导致浏览器在默认line-height: normal时，行盒被放大。

修复方式是在全局样式中加一行：

table td { line-height: 1.4; }

并将表格布局从line-height: normal改为固定值。调整后，中文和英文的垂直占位回归一致，页面布局恢复正常。

这个案例说明，在引入新字体时，一定要同步检查行高。判断标准很简单：如果字体换了之后，页面垂直间距的比例变得不符合预期，优先找line-height相关设置，而不是怀疑其他CSS属性。

7.3 排查工具与调试心得

• 浏览器DevTools可以选中文本元素，查看Computed样式中的line-height与font-size数值。
• 使用Range API getBoundingClientRect()快速测量文本视觉高度。
• 在Canvas中，通过measureText()打印所有metrics字段，观察actualBoundingBoxAscent/Descent。
• 如果是SVG，利用getBBox()或getComputedTextLength()辅助定位。

实测下来，最容易被忽视的是“DevTools显示的行高数值”不等于“文本视觉高度”。后者要用实际渲染边界去量，而不是看computed样式。拿DevTools的网格标尺直接卡文字的像素边缘，是最直观的方法。遇到复杂字体，直接在代码里临时插入一个测量节点，输出rect信息，比肉眼判断更准确。

8. 个人经验总结与后续扩展

写到这里，这套font-size与字体height关系背后的逻辑基本梳理清楚了。我自己在项目里有一个习惯，凡是要精确控制文本垂直位置的地方，就先写一个测量函数，把字体的ascent、descent、lineGap全部拉出来，看着数值做决策，而不是凭感觉调像素。

有一个技巧值得分享：如果你在做可视化编辑器或海报工具，可以把常见字体的度量信息缓存成JSON。需要在Canvas里精确排印时，直接查表，不依赖实时字体加载。这样性能更好，渲染结果也稳定。做法很简单，初始化时加载字体，用opentype.js读取ast和hhea表，序列化后存下。

{ "fontName": "NotoSansSC", "unitsPerEm": 1000, "ascender": 1160, "descender": -320, "lineGap": 0 }

后续如果要做更复杂的排版，例如按行绘制整段富文本，这个JSON表会是非常好用的基础数据。

这个主题还可以往几个方向继续扩展：可变字体（variable fonts）会在fonts里面增加动态metric轴，影响行高计算；Web渲染里的字形轮廓hinting与font-size奇偶性也会影响垂直像素对齐；还有无障碍排版中，如何权衡可读性与行高。这些都是值得继续钻研的方向。

如果这篇文章能帮你省下水磨工夫，那就很值了。接下来，找一个实际项目里的按钮或文字块，打开DevTools量一量，再回来看看这个模型，你会对字体排印有完全不一样的掌控感。