line-height不撑开span自身盒模型，而是设定其所在行框的最小高度；span作为行内非替换元素无独立content box，其视觉高度由行框决定，浏览器据此推算整行最小高度。
line-height 不是“撑开”span，而是定义行框最小高度
它根本没作用在 span 自己的盒模型上——span 作为行内非替换元素，没有独立的 content box 高度可被“撑”。真正被设定高度的是它所在的那一行，即浏览器自动创建的匿名 行框（line box）。你看到的“span 变高了”，其实是整行被拉高后，span 所在的行内框（inline box）随之填满该行框所致。
常见错误现象：span { line-height: 40px; } 单独写在一个空 div 里，开发者工具里选中 span 看不到高度变化；但选中父 div，getBoundingClientRect().height 就是 40px。这不是 bug，是渲染机制使然。
- 必须有可形成行框的上下文（比如包裹在
div、p中） - 该行不能被其他更高
line-height或vertical-align的兄弟元素主导 - 父容器不能设
height或max-height压制行框自然高度
数值类型决定 line-height 是“活的”还是“死的”
用 line-height: 1.5 和 line-height: 24px 效果可能天差地别，关键在继承逻辑：
line-height: 1.5 是无单位数值，子元素继承的是乘数，计算基于自身 font-size。例如父 font-size: 16px，子 font-size: 12px，子实际行高 = 12px × 1.5 = 18px。
立即学习“前端免费学习笔记（深入）”；
line-height: 24px 是绝对长度，子元素直接继承 24px，不管自己字号多小——10px 字号配 24px 行高，视觉上就是大片空白；而 20px 字号配同样 24px 行高，就显得局促。
line-height: 150% 表面像相对值，实则继承的是父级计算后的像素值（如父 font-size: 16px → 24px），子元素再怎么调字号，行高也不变。
为什么 inline 元素设 height 无效，但 line-height 有效
height 属性对 display: inline 元素完全无效，这是 CSS 规范明确规定的。而 line-height 虽然不直接设置元素盒高，但它参与行框构建规则——浏览器必须确保该行内框能容纳指定的基线间距，于是整行被强制拉到对应高度。
换句话说：height 是想“管住自己”，但 inline 元素没资格被这么管；line-height 是“影响别人（行框）”，而行框必须尊重它。
若真需要显式控制一个内联元素的高度，得改 display: inline-block，再配合 line-height + vertical-align: middle 或显式 height。
字体度量（ascent/descent）让 line-height 实际效果不等于计算值
即使设了 line-height: 1，浏览器仍可能让行框略高于 font-size，因为不同字体的上升部（ascent）和下降部（descent）高度不同，浏览器要预留渲染安全区。OpenType 字体在 Chrome 和 Firefox 中解析 ascent/descent 的策略略有差异，同一段代码在两浏览器中可能差 1–2px。
Web Font 加载未完成时更明显：fallback 字体（如 sans-serif）的度量与目标字体不一致，导致行高突变、布局抖动。这不是 line-height 写错了，是字体加载过程中的固有风险。
所以别依赖 line-height × 行数 精确算总高；用 max-height + overflow: hidden 控制截断，比手动计算可靠得多。
