line-height 无效的主因是元素类型不支持或 display 值不当；继承时无单位值才随字号缩放；需配合 vertical-align 或 flex 才实现垂直居中；字体度量会影响实际行高。
line-height 设置后文本没变化？先看元素是否支持行高
line-height 只对**块级元素、替换元素（如 img）和行内盒（inline boxes）** 生效，对纯 span 这类行内非替换元素，若未设置 display，其本身不生成行框，line-height 不会直接影响外观。常见误判是给一个空 span 或仅含文本的 span 直接设 line-height: 2，结果毫无反应。
实操建议：
- 检查目标元素的
display计算值：用浏览器开发者工具看「Computed」面板中的display，确认不是inline（除非它在行内上下文中参与行框构建） - 若需独立控制某段文字行高，优先包裹在
div、p等块级容器中，或显式设display: inline-block -
line-height对input、button等表单控件默认无效——它们的行高由height+padding+ 字体大小共同决定
继承行为导致子元素行高“意外放大”
line-height 的数值单位决定继承方式：无单位数值（如 1.5）是可继承的倍数，会乘以子元素自身的 font-size；而带单位的值（如 24px、1.5em）会被计算为具体像素后继承，不再随子元素字号变化。这是最常被忽略的根源。
例如父元素设 line-height: 1.6，子元素 font-size: 12px，则实际行高 = 12px × 1.6 = 19.2px；若父元素用 line-height: 1.6em，且父 font-size 是 16px，那子元素继承的是 25.6px 固定值，与自身字号无关。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 全局排版推荐用无单位数值（如
line-height: 1.5），保证缩放一致性 - 需精确控制某子元素行高时，直接在其上重写
line-height，不要依赖继承 - 避免混用
em和无单位值——line-height: 1.5em在嵌套多层时极易失控
line-height 与 vertical-align 共同作用才影响视觉垂直位置
单独设 line-height 并不会让文本“居中”或“下沉”，它只设定行框（line box）高度；真正决定文本在该行框中上下位置的是 vertical-align（对行内元素）或 align-items（对 flex 容器子项）。
典型现象：给 a 标签设了 line-height: 40px，但文字依然贴顶——因为 a 默认 vertical-align: baseline，基线对齐导致上方留白远大于下方。
实操建议：
- 块级元素（如
div）内单行文本居中：同时设line-height等于容器height，并确保无padding/border干扰 - 行内元素（如
span、img）需垂直居中：设vertical-align: middle或vertical-align: text-bottom，配合合适的line-height - 现代布局优先用
display: flex; align-items: center替代line-height居中，更可控且兼容多行
字体度量（ascent/descent）吃掉部分 line-height
line-height 定义的是行框总高度，但浏览器会把字体自身的上伸部（ascent）和下延部（descent）纳入计算，剩余空间才均分到上下。这意味着即使设了 line-height: 1，也可能有额外空白——尤其使用思源黑体、PingFang SC 等字体时更明显。
可通过 font-metrics-overrides（实验性）或 text-top/text-bottom 微调，但最稳妥方式是接受这个事实，并用 box-sizing: border-box + 显式 height 控制容器尺寸。
实操建议：
- 调试时打开 chrome DevTools 的「Layout」面板 → 勾选「Show layer borders」和「Show paint rectangles」，观察实际行框范围
- 若需像素级对齐，放弃依赖
line-height单独撑高，改用padding或flex - 同一
line-height值在不同字体下渲染高度可能差 2–3px，不要跨字体强求一致
真正难处理的从来不是 line-height 本身，而是它和 font-size、vertical-align、字体度量、盒模型之间的隐式耦合。调的时候别只盯着一个属性，打开开发者工具逐层看 computed 值，比查文档更快定位问题。