根本原因是浏览器对字体度量和基线对齐策略不同：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，它只管“没人管的时候怎么算”。

小红书长文-谷歌浏览器

在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。

下载

引入顺序和常见踩坑点

行高修复失效，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 的旋转场景。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！