line-height 应使用无单位值（如1.5）而非px或em，因px在移动端易失准、em会继承叠加；按钮等控件需用flex居中并显式设height+padding，避免依赖line-height。
line-height 用 px 值在小屏上直接失效
固定像素值（如 line-height: 20px）在移动端极易失准，因为系统可能强制放大字体（尤其 Android WebView 或 UC 浏览器），而行高不会同步放大。比如你设了 font-size: 12px + line-height: 16px，UC 会把字号拉到 16px，但 line-height 还是 16px，结果行框被压缩，文字挤成两行或底部露白。
实操建议：
- 一律改用无单位值：
line-height: 1.5（推荐）、line-height: 1.4，它会乘以当前font-size动态计算，响应式友好 - 避免
line-height: 1.2em——em会继承、叠加，容易失控 - 真机验证时，打开 Chrome DevTools 的 Computed 面板，看最终渲染出的像素值是否随字号等比变化
按钮里设 line-height 基本没用
Firefox 和部分 Android WebView 对 button、input[type="submit"] 强制应用 line-height: normal !important，你写的 line-height 直接被 UA 样式覆盖。Chrome/Safari 虽支持，但只影响文字基线位置，不改变按钮整体高度。
常见错误现象：
- 写了
line-height: 44px+height: 44px，文字仍偏上 2–4px（Safari 尤其明显） - 父容器是
display: flex，子按钮又设了line-height，结果按钮被撑高、文字卡顶 - 用了自定义中文字体（如 Inter、PingFang SC），ascent 占比不同，同一
line-height下视觉位置飘移
正确做法：显式设 height + padding，并加 box-sizing: border-box；需要垂直居中，用 display: flex; align-items: center，别依赖 line-height。
Safari（iOS 15+）对中文 line-height 渲染最不可靠
iOS Safari 默认用英文度量（如 -apple-system 的 ascent/descent）算中文字体行高，导致文字“浮”起 2–4px。再加上隐式 vertical-align: baseline 和默认开启的 -webkit-text-size-adjust: auto，问题被层层放大。
必须做的三件事：
- 给按钮加
-webkit-appearance: none+vertical-align: middle - 父容器写
-webkit-text-size-adjust: 100%（iOS Safari 专属） - 放弃
line-height居中，改用display: flex; justify-content: center; align-items: center，且父容器要有明确高度（不能是height: auto）
字体度量差异才是跨浏览器不一致的根因
Chrome 按 em-box 高度算行框，Firefox 更依赖字体内置的 ascent/descent 值。Web Font 加载前后，ascent/descent 比例一变，line-height: 1.4 渲染出的实际像素就可能差 2–3px——用户看到的就是文字“突然上浮”。
能缓解，但无法根除：
- 全局统一用系统字体栈（如
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial） - 关键控件（按钮、输入框）优先用
line-height: normal+padding微调，而非数值 - 所有
img、svg、input显式加vertical-align: middle，防止 baseline 错位牵动整行高度
最易被忽略的一点：line-height 不是独立属性，它和字体、渲染引擎、UA 样式、甚至 meta viewport 设置咬合在一起。调完一个值，得在 iOS 真机、Android 主流机型、Chrome/Firefox 桌面版全跑一遍，光看模拟器没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
