CSS line-height数字与百分比的区别及最佳实践

一个被忽视多年的 CSS 细节

即使是写了多年 CSS 的开发者，也可能对 line-height 的一个关键行为存在误解。最近一位资深前端开发者坦言：他一直以为自己理解 line-height，直到最近才意识到——无单位数字（unitless number）和百分比（percentage）在 line-height 上的表现并不相同。

这个差异在大多数情况下不明显，但一旦涉及到不同字号的文本嵌套，就会暴露出来。理解这个区别，能帮你避免一些难以排查的 CSS 排版 bug。

要理解这个问题的本质，需要先了解 CSS 的继承机制。CSS 的继承（Inheritance）是层叠样式表最核心的设计理念之一。并非所有属性都会继承——例如 border、margin、padding 等盒模型属性默认不继承，而 color、font-family、line-height 等排版相关属性则会自动从父元素传递到子元素。继承分为两种情况：继承「指定值」（specified value）还是继承「计算值」（computed value）。line-height 的无单位数字恰好是少数继承指定值的情形，这使得它在 CSS 规范中成为一个特殊且重要的案例。

无单位数字 vs 百分比：核心区别在哪里

推荐写法：无单位数字

大多数开发者习惯这样设置行高：

body {
  line-height: 1.5;
}

这里的 1.5 是一个无单位数字，通常设置在 body 上全局继承。它的行为是：每个元素都根据自身的 font-size 重新计算行高。

也就是说，1.5 这个「比例」会被继承下去，而不是计算后的具体像素值。子元素拿到的是「乘数 1.5」，再乘以自己的字号，得到属于自己的行高。

在 CSS2.1 规范（以及后续的 CSS Inline Layout Module Level 3）中，line-height 的值类型被明确区分为：normal、<number>、<length>、<percentage>。规范特别指出，当值为 <number> 时，「used value」是该数字本身乘以元素自身的 font-size；而当值为 <length> 或 <percentage> 时，computed value 在声明元素上就已经确定为绝对长度，后代元素继承的是这个绝对长度而非比例因子。这一设计是有意为之的，旨在为开发者提供两种不同的行高控制策略。

容易踩坑的写法：百分比

如果改用百分比：

body {
  line-height: 150%;
}

表面上看起来效果几乎一样，但继承机制完全不同。当你使用百分比（或其他带单位的值如 px、em）时，浏览器会在声明的那个元素上就把行高计算成一个固定值，然后把这个已经算好的具体数值继承给所有子元素。

这意味着，如果子元素的字号和父元素不同，它继承到的行高依然是按父元素字号算出来的固定值，而不会重新按自己的字号计算。

用 DevTools 验证 line-height 的继承行为

使用浏览器开发者工具可以直观验证这个差异。现代浏览器的开发者工具（DevTools）提供了「Computed」面板，它显示的是经过层叠、继承和计算后最终应用到元素上的属性值。与「Styles」面板显示的规则声明不同，Computed 面板展示的是浏览器实际渲染时使用的绝对值。对于 line-height，它会显示最终的像素值，这让开发者可以直观对比不同元素的实际行高，迅速判断是否存在继承异常。Chrome DevTools 还支持在 Computed 面板中点击属性值追溯其来源规则，这对排查继承链问题尤为高效。

当使用无单位数字时，选中不同的段落，可以看到行高被逐个元素独立计算：

• 一个较大字号的段落，计算出的行高约为 38.8px
• 一个较小字号的段落，计算出的行高约为 23.2px

这非常合理——字号更小的元素乘以 1.5，自然得到更小的行高。之所以出现 38.8、23.2 这样的「怪数字」，是因为使用了 clamp() 流体字号，字号本身就不是整数。

clamp() 是 CSS 中的数学函数，语法为 clamp(最小值, 首选值, 最大值)。在流体排版（Fluid Typography）中，开发者常将 font-size 设为类似 clamp(1rem, 2.5vw, 2rem) 的写法，使字号在视口宽度变化时平滑缩放，而不是依赖传统的媒体查询断点式跳变。这种方式的副作用是字号在大多数视口宽度下都不是整数像素值，因此乘以 line-height 后也会得到小数像素的行高。

百分比导致的行高异常

关键的对比出现在使用百分比时。同一个明显字号更小的元素，行高却依然显示为 38.8px，和大字号元素一模一样。

原因就在于：百分比会在设置它的那个元素上把所有数学运算一次性完成，得到一个固定的行高值，再原封不动地继承给所有后代元素。于是小字号文本被套上了为大字号计算的行高，视觉上就显得行距过大、比例失调。

为什么 line-height 应该用无单位数字

从上面的对比可以得出明确结论：

• 无单位数字：继承的是「比例」，每个元素按自身 font-size 重新计算，排版比例始终协调
• 百分比 / 带单位值：继承的是「计算结果」，一旦子元素字号变化，行高不会跟着调整，容易出现排版异常

这也是为什么 CSS 社区和 W3C 规范长期推荐优先使用无单位数字来设置 line-height。它不仅写法简洁，更重要的是符合「行高应该随字号自适应」的直觉预期。

值得一提的是，这个原则并非 line-height 独有。在 CSS 中，类似的「无单位 vs 有单位」行为差异也出现在其他场景中，例如 zoom 属性和部分 SVG 属性。理解「继承的是比例还是计算值」这一底层逻辑，有助于在遇到类似问题时举一反三。

line-height 设置的实践建议

1. 默认使用无单位数字：在 body 或全局样式中写 line-height: 1.5，让整个页面的行高比例自动适配各级字号。
2. 避免使用百分比或固定单位：除非你明确需要「锁死」某个具体行高值（例如在固定高度的按钮中精确垂直居中文本），否则不要用 150% 或 24px 这类写法。
3. 注意流体字号场景：当使用 clamp() 等流体字号时，无单位行高能确保行距始终与实时字号匹配，这一点尤为重要。在响应式设计日益普及的今天，流体排版已成为主流趋势，搭配无单位 line-height 可以让文本在任何视口宽度下都保持良好的可读性。
4. 善用 DevTools 排查：如果发现某处行距诡异，选中元素查看「计算值（Computed）」，往往能立刻定位是不是 line-height 继承出了问题。特别注意对比父子元素的 computed line-height 值——如果子元素字号明显不同却行高相同，大概率就是百分比或固定单位继承导致的。
5. CSS Reset/Normalize 中的注意事项：许多流行的 CSS Reset 库（如 modern-normalize）已经默认使用无单位数字设置 line-height。如果你的项目使用了自定义的全局样式重置，务必检查其中的 line-height 写法是否合理。

小结

line-height 看似是再基础不过的 CSS 属性，却藏着一个容易被忽视的继承行为差异。无单位数字继承比例、逐元素计算；百分比继承的是已经算好的固定值。理解这一点，不仅能避免难以排查的排版 bug，也再次提醒我们：即便是熟悉多年的技术，也值得时不时回头重新审视基础。

从更广的视角来看，CSS 中的许多「坑」都源于开发者对「值在何时被计算、以何种形式被继承」缺乏清晰的心智模型。line-height 的这个案例是一个绝佳的教学样本——它提醒我们，表面上看起来等价的写法（1.5 vs 150%），在浏览器的层叠与继承机制下可能有截然不同的语义。

核心要点