line-height直接决定行盒的最小高度，即行盒高度的计算基准；浏览器取该行所有inline box中最大的line-height值（或字体度量推导值）作为行盒高度，影响父容器撑高、文本留白及测量结果。
line-height 直接决定行盒（line box）的最小高度
它不是“影响”行盒高度，而是**就是行盒高度的计算基准**。浏览器先为每个行内元素生成一个“行内框”（inline box），再把同一行的所有 inline box 堆进一个“行盒”里；这个行盒的垂直高度，取所有参与元素中最大的 line-height 值（或由字体度量推导出的等效高度）。你看到的文本上下留白、父容器被撑高、getBoundingClientRect().height 返回的值，本质上都是这个行盒高度的体现。
常见错误现象：span { line-height: 32px; } 写在空 div 里没反应？其实是你没选对测量目标——测 span 自身返回的是 0（它是 inline 元素），必须测它的父 div 或用 display: inline-block 强制生成可测盒子。
- 行盒高度 ≠ 字体大小，也 ≠
height属性值（对 inline 元素无效） - 若该行只有纯文本，且无其他 inline 元素，则行盒高度 ≈ 父级
line-height值 - 若混有图片、
vertical-align: top的元素，行盒高度会重算为“最高上沿到最低下沿”的覆盖范围，line-height只提供默认底线
数值型 line-height（如 1.5）和带单位型（如 24px）行为完全不同
这直接影响响应性和继承逻辑，不是写法偏好问题，而是计算机制差异：
-
line-height: 1.5是相对当前元素font-size计算的：子元素继承后，会用自己的font-size× 1.5，适合响应式 -
line-height: 24px是绝对长度，不随字号缩放；父设24px，子即使font-size: 12px，行高仍是 24px，极易导致小字挤成一团或大字留白失控 -
line-height: normal由浏览器按字体内置的 ascent/descent + 经验值估算，不同字体结果可能差 3–6px，不适合像素级对齐
典型踩坑：移动端用 font-size: clamp(14px, 4vw, 20px) 却配 line-height: 24px，横屏时行高固定不变，文字视觉密度突变。
立即学习“前端免费学习笔记（深入）”；
为什么给 inline 元素设 height 没用，但 line-height 却能“撑高”父容器
因为 CSS 规范明确禁止对非替换的 inline 元素（如 span、a、strong）应用 height 和 width —— 它们会被忽略。你感知到的“高度”，其实是它所在的那一行被撑开后的结果。
- 父容器（如
div）是块级元素，其 content box 高度由内部所有行盒堆叠决定 - 哪怕只有一个
span，只要它在可形成行框的上下文中（即没被display: none或float干扰），浏览器就会为它创建匿名行框，line-height就生效 - 想让
span自己有可测量高度？得改display: inline-block或display: inline-flex，但它就不再是行内框了，vertical-align行为也会变
真正要控制的是行盒本身，而不是幻想给 span 加个 height 就能立竿见影。
line-height 对 vertical-align 的实际作用是“提供对齐锚点”，不是直接改变位置
vertical-align 不是设置元素离顶部多少像素，而是指定该元素的某条线（baseline / middle / top）如何与**当前行盒的基线或中线对齐**。而行盒的基线在哪、中线在哪，恰恰由所有 inline 元素的 line-height 和字体度量共同决定。
- 默认
vertical-align: baseline：文字基线对齐，但图片底部会预留 descender 空间，造成视觉错位 -
vertical-align: middle：浏览器需计算整行的中线位置，若某元素line-height远大于其他，会拉高整行，导致中线偏移 -
vertical-align: top或bottom：强制以行盒的上/下边缘为参考，此时行盒高度会被重算为“最高元素上沿到最低元素下沿”，line-height只作为初始输入参与这次重算
所以别单独调 vertical-align，它永远在和 line-height 打配合；调错一个，另一个的表现就全乱。
