line-height 在移动端不可靠，因 Safari 和 Android WebView 依据字体 ascent/descent 渲染行框，中文字体 fallback 差异导致视觉重心浮动 ±2–4px；按钮含图标、响应式字号、Flex/Grid 布局下 line-height 失效，应改用 flex + align-items:center 并清除 UA 样式与 text-size-adjust。
line-height 在移动端不准，根本不是数值写错了
它在 Safari 和 Android WebView 里压根就不是按“容器中心”算的。浏览器拿字体文件里的 ascent 和 descent 字段去生成行框（line box），而中文字体在 iOS 和安卓系统上 fallback 逻辑不同：Safari 倾向用英文度量渲染中文，Android 则常匹配不到中文字体 family name，导致同一行高下，文字视觉重心浮动 ±2–4px。
为什么 line-height: 44px + height: 44px 在真机上还是偏上
这不是你漏写了 white-space: nowrap 或 box-sizing: border-box——那些是基础，但还不够。关键干扰来自：
-
自带 UA 样式：-webkit-appearance: button+ 隐式vertical-align: baseline，Safari 9.1 以后一直没彻底清掉 - iOS 15+ 默认启用
-webkit-text-size-adjust: auto，小于 16px 的字号会被强制放大，行高重算失准 - 系统字体如
PingFang SC的 ascent 占比约 82%，而Microsoft YaHei是 76%，数值一样，基线位置却不同 - 哪怕只加一个
图标，它默认vertical-align: baseline，就把整行“拉高”
别调 line-height 数值了，直接换方案
以下三种场景，line-height 已经不是“不够好”，而是“不可信”：
- 按钮含图标（
/ - 用了 CSS 变量控制字号，比如
font-size: clamp(1rem, 2.5vw, 1.25rem) - 父容器是
display: flex或display: grid—— 此时line-height对垂直对齐完全无效
此时写三行 Flex 更省事：display: flex + justify-content: center + align-items: center。但注意：必须显式清除 line-height 干扰，否则 Safari 会继承 UA 的 line-height: normal 导致跳动。
最容易被忽略的兼容细节
Flex 写完了不等于完事。Safari 的坑藏在默认行为里：
-
的 UA 样式无法被* { margin: 0; padding: 0; }清除，必须加-webkit-appearance: none - 务必加
-webkit-text-size-adjust: 100%，这是 iOS Safari 专属，禁用自动缩放 - 如果按钮高度要严格对齐原生 App（比如
height: 44px），padding比 Flex 更可控——它不依赖布局上下文，也不吃字体度量影响
真正卡住的那 1px，往往不在代码里，而在字体特性、UA 样式和系统 fallback 的夹缝中。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
