padding-top百分比不按父元素高度计算，是为了避免“高度依赖padding、padding又依赖高度”的循环依赖导致布局无法收敛；w3c规范强制其统一基于包含块宽度计算，flex子项默认按flex容器content box宽度算，table-cell中则被规范定义为无效。
padding-top 百分比为什么不是按父元素高度算
因为浏览器 layout 阶段无法求解循环依赖：如果 padding-top: 50% 按自身或父元素高度计算，而该高度又由内容 + padding 共同决定，就会陷入“高度依赖 padding，padding 又依赖高度”的死循环。W3C 规范强制所有 padding 百分比（包括 padding-top、padding-bottom）统一锚定到包含块的宽度，这是唯一能保证布局收敛的确定值。
flex 子项里 padding-top: 10% 到底按谁的宽度算
默认情况下，它按flex 容器的 content box 宽度算，不是子项自己伸缩后的宽度，也不是 flex 容器的高度。
容易踩坑的是：
- 如果子项没设
flex: 1或width: 100%，它的计算宽度就是内容撑开的宽度（比如只有120px），那padding-top: 10%就只有12px，看起来几乎无效 - 要让
padding响应 flex 容器宽度，必须先让子项“占满”可用空间：flex: 1或width: 100% - 子项若设了
position: absolute，包含块会跳转到最近定位祖先，不再是 flex 容器
display: table-cell 为什么 padding 百分比完全无效
display: table-cell 是 CSS 2.1 明确规定的例外：所有 padding 百分比值被当作 0 处理，主流浏览器一致执行。这不是 bug，是规范行为。
如果你看到 padding-top: 20% 在 table-cell 里没生效，不要调样式，直接换 display 类型或改用固定像素值。
怎么验证当前 padding-top 百分比到底参照谁
别靠视觉猜“像不像”，用可测量方式定位包含块：
- 打开 DevTools，检查父容器是否设置了
position: relative、absolute或fixed——这会改变子元素的包含块 - 拖动窗口观察子元素
padding是否随宽度线性变化 - 把实际
padding-top的像素值，反向除以你怀疑的宽度，就能确认基准（比如得到0.2，基本就是20%）
真正容易被忽略的，是“包含块”未必等于“直接父元素”——遇到 padding 百分比异常时，第一反应不该是怀疑浏览器，而是逐层检查定位上下文和宽度来源，尤其是 position、display、flex、grid 这些会重定义包含块的属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
