根本原因是浏览器对字体度量解读不同：chrome依em-box、firefox依ascent/descent、safari叠加ios缩放与旋转干扰；web font加载会放大差异，line-height: normal实际值在chrome与safari下可能相差2px。
line-height数值计算依赖字体度量，而各浏览器读取方式不同
根本原因不是 CSS 写错了，而是 Chrome、Firefox、Safari 对同一 line-height: 1.5 的底层解释逻辑不一致：Chrome 主要依据字体的 em-box 高度推算行框，Firefox 更依赖字体内部的 ascent 和 descent 值，Safari 还叠加了 iOS 缩放与旋转时的动态调整。这些差异在系统字体下尚可接受，一旦引入 Web Font（如 Inter、Noto Sans），因不同字体的 ascender/descent 比例天差地别，line-height: 1.4 在加载前后可能产生 2–3px 跳变。
line-height: normal 不是“安全值”，它实际值由字体决定
line-height: normal 看似稳妥，实则最不可控——它让浏览器自行查字体度量表返回一个无单位值，而这个值在 Chrome 和 Safari 下可能相差 2px，在旧版 Edge 中甚至用百分比基线偏移计算。尤其当父元素未显式设 font-size 时，继承链中任意一环的字体切换都会牵动整行高度。
- 避免在按钮、输入框等需像素级对齐的场景用
line-height: normal - 若必须用，务必搭配显式
font-size和vertical-align: middle控制内联元素基线 - 检查 computed 样式里
line-height的实际返回值，而不是只看声明值
移动端 line-height + height 组合容易失效
在 Android 或 iOS 上写 height: 44px; line-height: 44px; 并不能保证文字垂直居中，尤其遇到 UC 浏览器或微信内置 WebView 时：它们会强制放大小于 12px 的字号（如 font-size: 0.12rem → 实际渲染为 16px），导致 line-height 计算基准错乱，文字撑出容器或留白异常。
- 优先放弃
line-height控制高度，改用padding+box-sizing: border-box - 对按钮类元素，用
display: flex; align-items: center;替代行高居中 - 必须用
line-height时，确保font-size≥ 12px，且加-webkit-text-size-adjust: 100%
normalize.css 不是万能解药，但它是起点
normalize.css 的作用是统一根元素的计算锚点：html { line-height: 1.15; }，并禁用 iOS 缩放干扰。但它不会覆盖你写的 line-height: 1.6，也不会修复你漏掉的 vertical-align。90% 的“用了 normalize 还不一致”问题，都出在加载顺序或被 UI 框架重置覆盖上。
- 确认
normalize.css是第一个引入的 CSS 文件，不能用@import - 搜索构建产物中是否同时存在
line-height: 1.15（normalize）和line-height: normal（某组件库 reset） - 若用 Ant Design 等框架，查其源码是否已重置
body的line-height
line-height，而是你没意识到它背后连着字体、基线、盒模型、加载时机四层依赖。只要其中一层松动，视觉就偏移。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
