line-height设为无单位数值（如1.5）时是缩放因子，子元素用自身font-size重新计算行高；它影响行框高度而非元素盒高，与height作用对象不同；在flex/grid中仍关键，用于调控行内内容对齐与行距。
line-height设成数值时，为什么子元素字体变大后行高没跟着变？
因为 line-height 设为无单位数值（如 1.5）时，它是个**缩放因子**，会乘以当前元素自身的 font-size 得到实际行高；但这个计算只在该元素上生效，不会继承“计算结果”，子元素用自己的 font-size 重新算一遍。
常见错误现象：div 设了 line-height: 1.5 和 font-size: 16px，里面 span 却设了 font-size: 24px，结果 span 行高还是按 16×1.5=24px 算的——不对，它其实按 24×1.5=36px 算，但父容器行高没扩容，导致文字视觉溢出或重叠。
- 用无单位数值最安全，推荐优先选
1.4~1.6范围 - 避免用
px或em设line-height，否则子元素无法自适应字号变化 - 如果父容器需严格控高（比如按钮内文），得额外给子元素加
vertical-align: middle或用 flex 对齐
inline元素里line-height为啥看起来没效果？
line-height 对 inline 元素本身不直接撑开高度，它影响的是**行框（line box）的上下间距**。真正决定行框高度的，是这一行里所有 inline 元素中最大的「内容区 + 行距」组合。
使用场景：导航栏里一堆 a 标签并排，设了 line-height: 40px 却发现上下留白不均——大概率是因为其中某个 a 有 padding 或 border，或者父容器是 inline-block 且未清除基线对齐间隙。
立即学习“前端免费学习笔记（深入）”；
-
line-height在 inline 元素上生效的前提是：它必须处于一个能生成行框的上下文（比如块级父容器） - 想让单个
a垂直居中，更可靠的做法是把父容器设为display: flex，子项用align-items: center - 若坚持用
line-height，确保父容器是块级且高度由它撑开，而不是靠height硬设
line-height和height同时设置，哪个优先？
两者不冲突，但作用对象完全不同：height 控制元素盒模型的**高度边界**，line-height 控制**行内内容的垂直排布节奏**。当 line-height 计算出的行框高度超过 height，内容会溢出（除非设了 overflow: hidden）。
性能影响小，但兼容性要注意：IE8 及更早版本对 line-height 在 table-cell 中的支持不稳定；现代浏览器里，只要不滥用 !important 覆盖，二者共存很常见。
- 按钮、卡片标题等固定高度容器，建议只设
height+display: flex+align-items: center，别依赖line-height居中 - 纯文本段落（
p、div）放心用line-height，它是可继承、可缩放的排版核心属性 - 设了
height又设line-height，务必检查 computed styles，确认实际行框是否被截断
line-height在flex或grid布局里还重要吗？
仍然重要，但角色变了：它不再负责“撑开容器”，而是影响**行内内容在主轴/交叉轴上的对齐精度**。比如 flex: 1 的卡片里放一段文字，line-height 过小会让文字贴顶，过大则底部留空难控制。
容易踩的坑：以为用了 flex 就可以删掉 line-height，结果多行文本在不同字号下基线错位、首行缩进异常、或者和图标对不齐。
- flex 容器中，
align-items: center对单行有效，但对多行文本，仍需line-height配合text-align控制内部节奏 - grid 区域里放段落，
line-height是唯一能微调行间松紧的 CSS 属性，row-gap管的是区域间距，不是文字行距 - 响应式中，建议用
clamp()配合line-height，例如line-height: clamp(1.3, 0.3vw + 1.4, 1.6)，比媒体查询更平滑
line-height 看似简单，但它在盒模型里横跨 content area、line box、inline formatting context 三层逻辑。最容易被忽略的是：它既不是 margin，也不是 padding，更不是 height，而是一种“隐形的节奏控制器”——改它之前，先看清楚自己到底想调什么。
