Chrome与Firefox的line-height渲染差异主因是字体度量和基线对齐策略不同：Chrome依em-box，Firefox依ascent/descent；Web Font会放大该差异。
line-height 在 Chrome 和 Firefox 中渲染差异明显
直接原因不是浏览器“bug”，而是默认字体度量（font metrics）和基线对齐策略不同。Chrome 倾向于按 em-box 高度计算行高，Firefox 更依赖字体内置的 ascent/descent 值；当使用非系统默认字体（比如 Web Font 或自定义 @font-face）时，这个差距会被放大。
实操建议：
- 不要只设
line-height: 1.5这类无单位值——它会继承父元素 font-size，但基线参考点仍由字体决定 - 优先用
line-height: normal+ 显式font-size组合，尤其在按钮、输入框等需要像素级对齐的控件里 - 若必须用数值，搭配
box-sizing: border-box和固定height，再用padding微调视觉居中，比纯靠line-height可靠
vertical-align 影响 inline 元素的基线对齐
vertical-align 不作用于块级元素，但它会悄悄改变行内盒子（span、img、input）与文本的相对位置，进而牵动整行 line-height 的实际占用高度。
常见错误现象：
- 一个
img默认vertical-align: baseline，底部会留出空隙（其实是为字母 “g”、“y” 留 descender 空间），导致父容器高度莫名变大 - 多个
inline-block元素混排时，只要有一个没设vertical-align: top/middle/bottom，就可能错位
解决办法很简单：
- 所有
img、input、button加上vertical-align: middle或vertical-align: top - 避免在
line-height已设死的容器里塞vertical-align: text-bottom这类语义模糊的值
@font-face 字体加载后 line-height 突然跳变
Web Font 加载前浏览器用后备字体渲染，加载完成后切换字体，而不同字体的 ascender/descent 比例不同，line-height: 1.4 在两套字体下实际像素高度可能差 2–3px —— 用户看到的就是文字“上浮”或“下沉”。
这不是 CSS 能完全拦住的问题，但可以收敛：
- 在
@font-face中显式声明font-display: swap，并配合size-adjust或ascent-override（仅 Chromium 支持）做度量模拟 - 更通用的做法：给文本容器加
min-height，值取「目标字体下预期行高 × 行数」，防止回流抖动 - 禁用字体加载时的自动重排？不行。但可以用
font-feature-settings: "liga" 0等临时占位技巧减小差异幅度
reset.css 里的 line-height 重置反而加剧不一致
很多 reset 库（如 Normalize.css）把 body 的 line-height 设为 1.15 或 1.6，看似统一，实则掩盖了字体基线差异。一旦项目引入新字体或换主题色，旧 line-height 就成硬编码陷阱。
更稳妥的起点是：
- 全局不设
line-height，让各组件按需声明（按钮用line-height: 1.2，正文用line-height: 1.7） - 用
font-familyfallback 链控制基线稳定性，例如："Inter", -apple-system, BlinkMacSystemFont, "Segoe UI"比单纯写"Helvetica"更一致 - 真要重置，请用
line-height: normal !important覆盖第三方库干扰，而不是设死数值
基线问题从来不是单点修复能搞定的，它藏在字体加载、display 类型、vertical-align 默认值、甚至 emoji 渲染路径里。改完记得在 Safari iOS 上连按三次 home 键切到后台再切回来——那里最容易暴露字体未就绪时的错位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
