line-height 应使用无单位数值（如1.6）而非带单位值（如24px），因其随字号动态计算、继承时保持相对性、适配响应式与用户缩放，避免行距失衡、文字重叠或跳行。
line-height: 1.6 和 line-height: 24px 渲染结果完全不同
浏览器对 line-height 的计算逻辑决定了它是否“随字号流动”：1.6 是乘数，每次都会用当前元素的 font-size 重新算出像素值；而 24px 是固定高度，一旦设死，就再也不会变。
比如父元素 font-size: 16px 时，两者都算出 25.6px 和 24px，看起来差不多。但子元素把字号放大到 20px 后：line-height: 1.6 自动变成 32px，行距同步宽松；line-height: 24px 还是卡在 24px，字大了、行高没涨，文字就挤在一起甚至重叠。
继承行为差异直接决定嵌套文本是否断层
这是最容易被忽略的关键点：带单位的 line-height 被继承时，子元素拿到的是一个**已计算好的具体值**（比如 24px），完全脱离自身字号；无单位数值（如 1.6）被继承时，子元素拿到的是“系数”，会用自己的 font-size 再乘一次。
-
p { line-height: 1.6; }→span { font-size: 1.5em; }→span行高 = 自身字号 × 1.6 -
p { line-height: 24px; }→span继承后就是24px，哪怕它的字号是32px，行高也还是 24px
这种差异在 <strong>、<em> 或自定义字体组件中极易导致行盒（line box）高度不一致，视觉上出现“跳行”或文字贴边。
立即学习“前端免费学习笔记（深入）”；
响应式与用户缩放场景下，带单位值必然失效
当用 rem 做根字号响应式（比如 html { font-size: 87.5%; }）、或用户开启系统级“更大字体”设置时，所有相对单位都会缩放，但 line-height: 24px 不会——它永远钉死在 24 像素。
此时正文可能缩到 14px，行高却仍是 24px，行距松垮；标题放大到 36px，行高还是 24px，文字上下挤压。而 line-height: 1.6 会自动适配：14px × 1.6 = 22.4px，36px × 1.6 = 57.6px，节奏始终一致。
更隐蔽的问题是邮件模板或 CMS 输出受限场景：你无法控制外部样式表，但只要内联写 style="line-height: 1.6;"，它就能稳稳生效；写成 style="line-height: 24px;"，一旦用户缩放页面，立刻失准。
em/rem 百分比这些“看似相对”的写法其实更危险
line-height: 1.6em 看似相对，实则依赖父元素的 font-size 计算，嵌套越深越容易意外放大；line-height: 160% 表面和 1.6 等价，但某些旧版浏览器在继承时会先转成绝对值再传给子元素，行为不可控。
真正安全的只有无单位数值：
- 它不依赖祖先，只认自己这一层的
font-size - 它不参与 CSS 层叠权重计算，不会因选择器优先级被意外覆盖
- 它和
font-size: 1rem、font-size: clamp()等现代响应式方案天然兼容
中文正文建议从 1.5 起步，混排英文或图标时可微调到 1.6；小字号（≤12px）别低于 1.4，否则降部（如 “g”、“y”）容易被裁切——这些细节，只有无单位值能稳住。
