line-height 推荐用无单位数值（如1.5），因其基于自身font-size、继承安全且响应式友好；用px或em易致行距塌陷或爆炸，内联元素需配合display或padding才显效。
line-height 属性值怎么选才不踩坑
直接说结论：line-height 推荐用无单位数值（比如 1.5），别用 px 或 em——否则子元素继承时会出人意料的行距塌陷或爆炸。
常见错误现象：父容器设了 line-height: 20px，里面套个 <h2></h2> 字号变大后，文字紧贴上下边，甚至被截断；或者用 line-height: 1.2em，结果每层嵌套都叠加计算，越深越稀疏。
-
1.5是相对当前元素自身font-size的倍数，继承安全，响应式友好 -
1.5em看似一样，实则基于父元素的font-size计算，嵌套后容易失真 -
20px是绝对值，子元素换字号后行高不会自适应，极易错位
内联元素（如 span、a）行高为啥经常不生效
line-height 对纯内联元素本身不产生“高度”，它只作用于其生成的行框（line box）——换句话说，它影响的是文字所在那条“假想横线”的间距，不是给 <span></span> 自己撑开盒子。
使用场景：你想让一行文字垂直居中在固定高的容器里？光靠 span 上设 line-height 没用；得设在块级容器（如 <p></p> 或 <div>）上，或者把 <code>span 变成 display: inline-block 再配合 vertical-align。
立即学习“前端免费学习笔记（深入）”；
- 对
<span></span>单独设line-height，浏览器会照算，但你几乎看不到变化 - 真正起效的是该
span所在的“行框”由其父块级元素的line-height决定 - 若必须控制单个内联元素视觉行距，改用
padding或margin更直接
line-height 和 vertical-align 一起用时的典型冲突
当父容器有 line-height，子元素又设了 vertical-align: middle（尤其是图片或 inline-block 元素），很容易出现“看起来没对齐”或“上下空隙忽大忽小”。
原因在于：vertical-align 对齐的是行框内的基线（baseline），而 line-height 决定了行框高度——两者共同决定元素在行内的垂直位置，但基线位置本身受字体、字号甚至 Unicode 字符影响。
- 图片默认按基线对齐，下方会留出字母 “g”、“y” 下延的空间，显得悬浮
- 解决办法：给图片加
vertical-align: top或vertical-align: bottom，比middle更可控 - 若需精确居中，建议把容器设为
display: flex，彻底绕开行框机制
移动端适配中 line-height 的隐性风险
某些安卓 WebView 或旧版 iOS Safari 在缩放字体（比如用户调大系统字号）时，line-height 为无单位数值仍可能表现异常——文字挤在一起，尤其在 <textarea></textarea> 或多行 <p></p> 中。
这不是 bug，是渲染引擎对“相对行高”的解释差异。关键点在于：行高最终要和字体度量（ascent/descent）协同，而不同引擎对这些度量的采样精度不一致。
- 保险做法：对正文文本，用
line-height: 1.6~1.7，避开1.4这类易触发截断的临界值 - 避免在
<input type="text">或<textarea></textarea>上依赖line-height控制高度，优先用height+padding - 如果用了自定义字体，务必检查其
line-gap和typoAscender是否被 CSS 重置覆盖
行高看着简单，实际是字体度量、盒模型、渲染管线三者咬合最紧的地方——改一个值，可能牵出跨浏览器、跨设备、跨字号的连锁反应。动手前先确认你到底是在调“文字呼吸感”，还是在修“布局断裂点”。
