根本原因是safari对line-height的解析逻辑与chrome不同，尤其在input、button、flex等场景下会静默忽略该属性；应改用height+padding+box-sizing组合控制高度，并通过computed面板和真机验证确保效果。
根本原因不是你设错了值，而是浏览器对 line-height 的解析逻辑、默认字体度量、盒模型处理方式不同——尤其当它和 input、button、flex 或内联元素混用时，Safari 很可能压根没按你写的执行。
为什么 line-height 在 input 上 Safari 完全不生效
Safari（尤其是 iOS 15.4 / macOS 12.3 之前）对表单控件的 line-height 渲染是“选择性忽略”：它不报错，但也不应用。常见现象包括：
- 给
input设line-height: 36px，Chrome 中文字垂直居中，Safari 中文字紧贴顶部 - 加了
padding后高度反而变矮或出现滚动条——因为 Safari 把line-height当作无效声明，只按内容撑高 -
vertical-align在input上完全无效，别试
真正可靠的做法是放弃 line-height 控制高度：
- 显式设置
height: 36px（而非依赖line-height） - 用
padding-top和padding-bottom微调文字上下位置 - 统一加
box-sizing: border-box，避免边框/内边距撑出意外高度
为什么 line-height: 1.5 在 Safari 里文字还是偏上
无单位数值（如 1.5）虽能继承缩放，但在 Safari 中仍可能因字体度量（ascent/descent）渲染差异导致视觉偏移，尤其在混合中英文、图标或使用 system-ui 字体时：
Plan Dubai Travel — Flights, Hotels, Burj Khalifa, Desert Safari, Malls & Itineraries
下载
规划您的迪拜之旅 — 哈利法塔观景、沙漠探险、迪拜购物中心购物、棕榈岛度假村及黄金市场砍价。还提供支持...
- 中文系统字体（如 PingFang SC、SF Pro）在 Safari 中 ascent 值常比 Chrome 高，文字自然“浮”得更靠上
- 如果父容器是
display: flex或display: grid，line-height对子元素文字的垂直定位完全失效——它只影响行框，不参与 flex item 对齐 - 子元素含
svg、img或inline-block元素时，baseline 对齐会把整行“拉高”，line-height看似没变，但视觉中心已偏移
验证方法很简单：打开 Safari 开发者工具 → 选中文字容器 → Computed 面板搜 line-height，看实际计算值是否等于你写的；再勾选 “Show layout bounds”，观察文字实际占据的垂直范围是否与容器高度重合。
哪些写法在 Safari 里特别危险
这些看似标准的 line-height 用法，在旧版 Safari（iOS 15.3 及更早）中极易出问题：
-
line-height: 0想“清空行高”？某些 Android WebView 和 Safari 会直接忽略，甚至让文字塌陷进上一行 -
line-height: 24px+font-size: clamp(1rem, 2.5vw, 1.25rem)：像素值无法响应缩放，文字变大后行距卡死不动 - 在
button或select上设line-height：Safari 和旧 Edge 基本无视，高度由内容或 UA 样式决定 - 给
span单独设line-height：纯内联元素不生成行框，该声明无视觉效果
替代方案更稳：
- 按钮/表单控件：用
display: flex; align-items: center; justify-content: center; - 多行文本截断：用
display: -webkit-box+-webkit-line-clamp，别依赖line-height × 行数 - 需要精确控制行框高度的场景：用
min-height+padding+box-sizing: border-box组合，绕过line-height的不可控性
最麻烦的不是值写错，而是 Safari 不提示、不报错、不警告，只是静默回退到 UA 默认行为。所以别信“看起来差不多”，一定要看 Computed 值 + outline 边界 + 真机验证。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
