CSS中所有padding百分比均基于包含块宽度计算，以避免“高度依赖padding、padding又依赖高度”的循环依赖；flex子项按flex容器content box宽度算，table-cell则忽略百分比。
因为浏览器 layout 阶段必须避免“高度依赖 padding，padding 又依赖高度”的死循环，所以 CSS 规范强制所有 padding 百分比（包括 padding-top 和 padding-bottom）统一以**包含块的宽度**为唯一计算基准——这不是浏览器 bug，也不是历史妥协，而是唯一能保证布局收敛的硬性设计。
padding-top: 50% 为什么不能按父元素高度算
如果允许 padding-top: 50% 按父元素当前高度计算，就会触发无法求解的循环：
- 父容器
height: auto，其最终高度 = 内容高度 +padding-top+padding-bottom - 而
padding-top: 50%又反过来依赖这个尚未确定的高度 - 浏览器在 layout 阶段无法收敛，只能放弃解析或进入未定义行为
用包含块的宽度作基准，就彻底切断了这个依赖链——宽度通常是已知、确定、可提前获取的值。
“父元素”不等于“包含块”，这点常被忽略
你写的 .parent { width: 300px; } 看似是基准，但实际起作用的可能是更上层的容器：
立即学习“前端免费学习笔记（深入）”；
- 若子元素设了
position: absolute，而祖父元素有position: relative，那它的包含块就是祖父元素，不是直接父元素 - flex 子项中，
padding: 10%默认按 flex 容器的 content box 宽度算，不是子项自己伸缩后的宽度 -
display: table-cell是明确例外：所有padding百分比被当作0处理，连计算都不走
验证方法很简单：打开 DevTools → Computed 面板 → 查看 padding-top 的像素值，再反向除以你怀疑的宽度，就能确认基准到底是谁。
为什么 margin 也按宽度算，且和 padding 共享同一套逻辑
margin-top 和 margin-bottom 百分比同样基于包含块宽度，原因一致：
- 防止
margin-bottom推高父容器高度，进而导致自身 margin 进一步增大，形成无限放大循环 - CSS 2.1 规范原文明确：“The percentage is calculated with respect to the width of the generated box's containing block. Note that this is true for 'margin-top' and 'margin-bottom' as well.”
- 这意味着
margin-top: 100%在父宽 200px 时就是 200px，哪怕父高只有 10px
真正卡住人的，从来不是公式记错，而是 inspect 时没点开 Computed 面板看一眼实际宽度来源——尤其是当上级用了 flex: 1、transform 或 grid 时，包含块可能早已悄悄切换。
