根本原因是各浏览器对默认字体的ascent、descent和line-gap度量值不同，且line-height:normal计算逻辑不一致；应统一font-family双栈、使用无单位line-height:1.5，并以flex+align-items替代height控制高度。
跨浏览器盒模型高度微调，根本不是字体“没选对”，而是各浏览器对默认字体的 ascent、descent 和 line-gap 度量值不同，且默认 line-height 计算逻辑不一致——哪怕你没写任何字体相关 CSS，这个差异也已生效。
为什么没设 font-family 也会出问题
每个浏览器都有自己的 UA 样式表，默认 font-family 不同：
- Chrome / Edge（Windows）：
font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif; - Safari（macOS）：更倾向
-apple-system，其字体度量中ascent普遍比 Windows 的 Segoe UI 高 1–2px - Firefox：在 Linux 上可能 fallback 到
DejaVu Sans，descent更深，行框整体被拉高
这些默认字体的垂直度量（ascent/descent/line-gap）不同，直接导致同一 font-size 下，浏览器计算出的“行高撑开空间”不同。而 line-height: normal（默认值）正是基于这些字体度量动态计算的，不是固定比例。
line-height: normal 在各浏览器里到底多“不正常”
line-height: normal 的实际像素值由字体度量 + 渲染引擎策略共同决定，无法预测：
立即学习“前端免费学习笔记（深入）”；
- Chrome 对中文常用字体（如
Microsoft YaHei）会额外加约2pxline-gap，确保可读性 - Safari 在 macOS 上对
-apple-system使用更紧凑的 baseline 对齐，但descent值偏大，导致 inline 元素底部留白更多 - Firefox 有时将
normal解析为font-size × 1.15左右，而 Chrome 可能是× 1.22，差值在font-size: 14px时就达 1px - 该值还会随系统缩放、辅助功能设置（如“增大文字”）实时变化，DevTools 里看到的 computed
line-height是运行时结果，非静态
如何让高度真正可控（不靠猜）
放弃依赖 font-family 或 line-height: normal，用显式组合封住变量：
- 强制统一基础字体栈：
font-family: -apple-system, BlinkMacSystemFont, "PingFang SC", "Microsoft YaHei", system-ui, sans-serif;（中英文双栈前置，避免 fallback 到不可控字体） - 禁用
normal：line-height: 1.5（无单位），它以当前font-size为基准计算，绕过字体度量差异 - 对 inline 元素（如
span、button）禁用 height，改用padding+line-height控制视觉尺寸 - 对需严格高度的容器（如导航栏），用
display: flex; align-items: center;替代height + line-height组合——flex 不依赖字体度量，只按内容区中心对齐
最容易被忽略的细节：伪元素和动态插入内容
即使主样式表控制得当，以下场景仍会悄悄破坏高度一致性：
-
::before/::after伪元素继承父级font-family，但若内容为空或含 Unicode 符号（如\200B零宽空格），其字体度量可能触发独立行框计算 - JavaScript 动态插入的文本节点，若未显式设置
font-family和line-height，会回退到 UA 默认，与静态 HTML 不一致 - Web Font 加载完成前，fallback 字体撑开的高度 ≠ 加载后真实字体高度，造成 layout shift；需用
@font-face的font-display: optional或swap配合size-adjust缓解
