根本原因是浏览器对字体度量和基线对齐策略不同：Chrome依em-box，Firefox依ascent/descent，Safari还叠加iOS缩放与旋转干扰；normalize.css通过统一html的line-height:1.15等基准值来收敛差异。
直接用 normalize.css 就能解决大部分浏览器行高不一致问题，但它不是靠“设死值”硬压，而是统一计算基准和继承逻辑——比如强制 html 的 line-height: 1.15，并禁用 iOS 缩放干扰。
为什么不同浏览器的 line-height 渲染结果不一样
根本原因不在你写的 CSS，而在浏览器对基础排版的默认处理差异：
- Chrome 和 Firefox 对
body默认line-height的继承策略不同，尤其当父元素没显式设值时 - Safari（尤其是 iOS）会在页面旋转或字体较小（
- IE/Edge Legacy 对
line-height的百分比计算存在基线偏移，和现代引擎不一致 -
font-family中 fallback 字体缺失时，各浏览器选字逻辑不同，间接影响行高表现
normalize.css 是怎么修正行高基准的
它不给你一个固定像素值，而是从根上统一排版起点：
- 在
html元素上声明line-height: 1.15，作为所有后代元素的计算锚点 - 移除
body的默认margin，避免外边距干扰行高视觉节奏 - 设置
-webkit-text-size-adjust: 100%，关掉 iOS Safari 的自动缩放机制 - 确保
form、pre、code等易出问题的元素显式继承line-height，而不是依赖浏览器猜测
注意：normalize.css 不会重写你写的 line-height: 1.6 或 line-height: 24px，它只管“没人管的时候怎么算”。
立即学习“前端免费学习笔记（深入）”；
引入顺序和常见踩坑点
行高修复失效，90% 是因为加载顺序或覆盖逻辑错了：
-
normalize.css必须是整个样式链中第一个生效的 CSS 文件——放在你自己的main.css之前，否则你的规则可能已经把html的line-height覆盖掉了 - 别用
@import在 CSS 里引入normalize.css：它异步加载，html规则可能晚于页面渲染 - Webpack/Vite 用户要检查构建产物里有没有重复打包：搜索输出 CSS 是否同时出现
line-height: 1.15（来自 normalize）和line-height: normal（来自某 UI 库 reset） - 如果用了 Ant Design、Element Plus 这类自带轻量 reset 的 UI 框架，它们可能悄悄重置了
body的line-height，得去查它们的源码或文档确认
后续自定义行高建议
有了 normalize.css 打底，你可以更安心地做设计层控制：
- 在
body上设一个全局line-height: 1.5或1.6，它会稳定继承下去 - 对
pre、code、textarea单独设line-height: 1.4，避免等宽字体撑开太多 - 慎用
line-height: normal：它的实际值由字体度量决定，Chrome 和 Safari 返回值可能差 2px - 如果项目要求极端精确（比如设计稿标注了 24px 行高），建议用
line-height: 24px+font-size: 16px组合，避开相对单位的浮动误差
真正容易被忽略的是：行高不一致往往不是孤立问题，它常和 vertical-align、font-size-adjust、甚至 text-rendering 一起作用。修完 normalize.css，记得在真机上测一测 iOS Safari 的旋转场景。
