line-height不是对齐指令而是撑开行框，其垂直居中仅在五项硬条件全满足时有效：height为明确像素值、white-space: nowrap、box-sizing: border-box且line-height等于内容区高度、无vertical-align干扰、父容器非flex/grid布局。
line-height 不是“对齐指令”，而是撑开行框
它控制的是行框（line box）的最小高度，不是文字本身的上下位置。当设为 line-height: 40px，浏览器会确保这一行文字所在的行框高至少 40px，并把文字的基线（baseline）放在这个行框的垂直中心——但基线本身不等于文字视觉中心，尤其对中文字体或小写字母（如 x、g、y）来说，ascent/descent 分布不均，顶部和底部留白天然不对称。
五项硬条件缺一不可，否则立刻失效
常见现象是写了 height: 40px 和 line-height: 40px，文字却偏上或偏下。这不是数值错了，而是以下任一条件没满足：
- 容器
height是明确像素值（不能是auto、%或min-height） - 内容强制单行：
white-space: nowrap（空格、换行符、长单词都会触发换行） -
box-sizing: border-box，且line-height等于「内容区高度」：即height - padding-top - padding-bottom - border-top-width - border-bottom-width - 容器内不能有
vertical-align（包括子元素上写的也会影响） - 父容器不能是
display: flex或display: grid（此时line-height对垂直对齐完全无效）
字体度量差异让“相同数值”在不同环境表现不同
同一套 CSS，在 Chrome、Safari、Android WebView 中渲染出的文字垂直位置可能差 2–4px，根源在于：
- 中文字体（如 PingFang SC、Microsoft YaHei）的 ascent/descent 比例不同，影响基线落点
- iOS Safari 15+ 默认用英文度量解析中文字体，导致 ascent 被高估，文字“浮起来”
-
font-feature-settings: "ss02", "cv05"等变体启用后，x-height 区域被抬高，小写字母视觉上更靠上 -
-webkit-text-size-adjust: auto（iOS 默认开启）会让小于 16px 的字号被强制放大，重算行高失准
混入 SVG 或图标时，baseline 对齐直接崩盘
SVG 默认是 display: inline，和文字一起按 baseline 对齐，但它自身的基线位置和文字不同，整行会被“拉高”，文字看起来就偏下了。这不是 line-height 失效，而是多个内联元素在争抢同一根基线。
立即学习“前端免费学习笔记（深入）”；
解决方式不是调 line-height，而是统一行为：
- 给图标加
vertical-align: middle（仅限纯 inline 场景，且父容器不能已有冲突的line-height） - 更推荐：整个按钮设为
display: flex，图标和文字都变成 flex item，align-items: center自动对齐中心轴 - 绝对不要在 flex 容器里再写
line-height——二者共存时文字会随字号缩放上下跳动
真正难处理的，是那些既要兼容 IE11、又得在 iOS Safari 上显示一致、还嵌了 iconfont 的按钮。这时候，line-height 是妥协起点，flex 是交付底线，而字体特性调试，往往才是最后卡住的那 1px。
