line-height直接决定行框高度，而非font-size；它与字体度量、vertical-align共同计算行框高，块级容器content高度由行框堆叠决定，inline元素height无效。
line-height 直接参与行框（line box）高度计算
浏览器渲染文本时，并不直接用 font-size 推算容器高度，而是基于「行框」这个中间结构。每个文本行都会生成一个行框，它的高度由该行中所有内联级元素（包括匿名内联盒）的 line-height、字体度量（ascent/descent）、vertical-align 共同决定。块级容器（如 p、div）的 content 区域高度，就是其内部所有行框堆叠后的总高——单行时，就等于那个行框的高度。
常见错误现象：div { font-size: 14px; line-height: 28px; } 渲染出 28px 高的内容区，哪怕文字本身只占约 16–18px（取决于字体）。这不是“撑开”，是浏览器按规范把行框高度设为 28px 后，自然填充了 content box。
inline 元素自身没有 height，但影响所在行框高度
span、em 这类 display: inline 元素的 height 属性完全无效；它们的垂直空间表现，只通过 line-height 参与父级行框计算来体现。
- 若父
p未设line-height，子span设了line-height: 32px，该行框高度通常取 32px（前提是无更高内联元素） - 若同一行有多个
span，分别设line-height: 20px和line-height: 40px，整行框高度取 40px -
vertical-align不改变行框高度，但会移动元素在行框内的基线位置，可能造成视觉“悬浮”或“下沉”
数值型 line-height（如 1.5）比像素/百分比更可靠
用无单位数值最安全，因为它作为乘数继承：子元素用自身 font-size × 该值重新计算行高，不会滚雪球放大。
对比：
-
line-height: 1.5→ 子元素font-size: 12px时，行高 = 18px -
line-height: 150%→ 父元素计算后得 30px（假设父font-size: 20px），子继承的是 30px 固定值，即使自己font-size: 12px也强行用 30px，极易挤压文本 -
line-height: 0会让行框高度塌缩至内容区（仅含 ascent + descent），常用于图标文字混排时隐藏文字，但需配合overflow: hidden
块级容器高度 ≠ line-height × 行数，但依赖行框堆叠逻辑
多行文本总高接近 line-height × 行数，但不严格相等——因为首行顶部、末行底部的半行间距可能被截断，且 OpenType 字体的 ascent/descent 在 Chrome/Firefox 中解析有 1–2px 差异。Web Font 加载延迟时，fallback 字体可能临时改变行高，导致布局跳动。
真正需要精确控制多行文本容器高度时，别靠手算：max-height + overflow: hidden 比 height + line-height 更稳；垂直居中则优先用 display: flex 或 grid，line-height 只适用于单行。
最容易被忽略的一点：line-height 影响的是 content 区域，不是整个盒模型。加了 padding 或 border 后，总高 = line-height + 上下 padding + 上下 border，很多人误以为 line-height 是“总高”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
