行内元素的padding-top/bottom确实生效但不参与布局计算，因它们仅在行框内绘制且不改变行高；推荐用display:inline-block解决，它启用完整盒模型并保留行内流特性。
行内元素的 padding-top 和 padding-bottom 确实渲染了，但不参与布局计算——这不是 bug，是 CSS 规范对 IFC（行内格式化上下文）的明确约定。
行内元素的垂直 padding 为什么“看不见效果”
根本原因在于：行内元素的高度由 line-height 和字体的 content-area（即“幽灵空白节点 strut”）共同决定，而 padding-top/padding-bottom 只在行框（line box）内部绘制，并不改变行框高度，也不影响相邻行的位置。
常见错误现象包括：
- 给
<span></span>加了padding: 20px 5px，背景色看起来有上下留白，但下方文字没被往下推 - 父容器设置了
line-height: 1.2，子<span></span>的padding-top: 30px被裁剪或与上一行文字重叠 - 空
<span></span>+ 大padding后，父容器clientHeight没变，但scrollHeight却增加了——说明垂直 padding 被计入可滚动区域，但不参与布局流
display: inline-block 是最可靠解法
它保留行内流特性（不换行、不独占一行），同时启用完整盒模型，让 padding、width、height 全部按预期生效。
立即学习“前端免费学习笔记（深入）”；
使用时注意三个易忽略点：
-
vertical-align默认是baseline，容易导致底部和文字基线不对齐，产生意料外的空白；建议显式设为middle或top - 若父容器设置了
font-size: 0来清除inline-block间隙，子元素中用em单位的padding会失效（因基准为 0） -
line-height仍作用于该元素的垂直对齐参考线，不是完全“脱离”行高体系
别用 vertical-align + line-height “硬调”上下间距
这种做法看似能“模拟”出 padding 效果，但实际非常脆弱：
- 依赖字体渲染细节，不同系统/浏览器下 baseline 位置可能偏移
- 当内容含图标、emoji 或多语言文字时，
vertical-align: middle可能失准 -
line-height是全局行框属性，调整它会影响所有同级行内元素，副作用不可控 - 无法单独控制某一个
<span></span>的上下留白，灵活性远不如inline-block
真正要控制垂直空间，就该让元素拥有自己的布局上下文——inline-block 是轻量、稳定、广泛兼容的选择。复杂点在于：它引入了 vertical-align 和 font-size: 0 这类隐性依赖，稍不注意就会在嵌套或响应式场景中翻车。
