根本原因在于浏览器对无单位line-height与固定单位的解析逻辑不同，导致Firefox和Chrome中实际像素值相差1–2px；line-height:1.5是相对计算并响应字体变化，而line-height:24px是绝对锁定且不随字体缩放。
根本原因不是你写错了 line-height，而是浏览器对“无单位数值”和“固定单位”的解析逻辑不同，加上默认字体继承链的微小差异，导致同一行 CSS 在 Firefox 和 Chrome 里算出的实际像素值可能差 1–2px。
line-height: 1.5 和 line-height: 24px 的行为完全不同
前者是相对计算，后者是绝对锁定。Firefox 对 line-height: normal 的默认实现约是 1.2，Chrome 约是 1.15，Safari 可能低至 1.08——这意味着如果你没显式重置，父容器字体变化时，子元素的行高不会同比例缩放。
-
line-height: 1.5：子元素按自身font-size计算，比如font-size: 16px→ 行高 = 24px；font-size: 20px→ 行高 = 30px，始终响应 -
line-height: 24px：无论子元素字体多大，行高永远卡死在 24px，文字可能被裁剪或堆在顶部 -
line-height: 1.5em：看似合理，实则危险——它按父级font-size计算，不随子级变化，等同于固定像素
图文混排时图片底部留白，其实是 line-height 拉的线
当 <img> 和文字同行显示（如列表项、卡片标题），line-height 直接决定内联上下文的基线位置。不同浏览器对 vertical-align: baseline 的基线判定依据不同，而这个基线又依赖于当前行的 line-height 和字体度量。
- 设
line-height: 0看似能清空间隙，但会导致文字不可见（行盒高度坍缩） - 设
line-height: 1可能让图片底部悬空，尤其在 Safari 中更明显 - 稳妥做法是给图文容器加
display: flex; align-items: center;，绕过内联基线逻辑 - 若必须用内联布局，统一
body { font-size: 16px; line-height: 1.5; }，再配合img { vertical-align: middle; }
表格单元格高度失控，别碰 <tr> 的 height
给 <tr> 设 height 基本无效：Chrome 完全忽略，Firefox 行为不稳定。真正起作用的是 <td> 的组合控制，而它的表现又直接受 line-height 影响。
立即学习“前端免费学习笔记（深入）”；
-
td { height: 44px; line-height: 44px; }能单行垂直居中，但前提是box-sizing: border-box，否则 padding 会额外撑高 -
vertical-align: middle和line-height在某些场景下冲突，尤其当单元格内容换行时 - 多行文本场景下，
line-height失效，应改用display: -webkit-box截断，或直接切为 Flex 布局 - 移动端需媒体查询微调：手机屏用
line-height: 1.4，桌面端用line-height: 1.65，且所有断点内必须保持无单位
最易被忽略的一点：哪怕你用了 normalize.css，它也不会重置 line-height 或 font-size 的默认继承——这些都得你自己在 body 或 :root 里明确声明，否则差异会从第一层继承就开始放大。
