CSS规范强制padding百分比（含top/bottom）统一按包含块宽度计算，以避免“高度依赖padding、padding又依赖高度”的循环依赖；flex子项按flex容器content box宽度算，table-cell中百分比无效。
因为浏览器 layout 阶段必须避免“高度依赖 padding，padding 又依赖高度”的死循环，所以 CSS 规范强制所有 padding 百分比（包括 padding-top 和 padding-bottom）统一按包含块的宽度计算——这不是 bug，是唯一能保证布局收敛的设计。
为什么不能按父元素高度算
如果 padding-bottom: 50% 按父元素高度计算，而父元素高度又由子内容 + padding 共同决定，就会陷入无法求解的循环：
- 父元素高度 = 内容高度 +
padding-top+padding-bottom - 但
padding-bottom又要等父元素高度确定后才能算 - 浏览器 layout 阶段直接卡住，放弃渲染或回退为 0
用包含块宽度作为唯一确定基准，每次计算都有明确起点，layout 才能稳定收敛。
flex 子项里 padding: 10% 到底按谁的宽度算
默认按 flex 容器的 content box 宽度算，不是子项自己伸缩后的宽度，也不是容器高度。但容易误判：
立即学习“前端免费学习笔记（深入）”；
- 若子项没设
flex: 1或width: 100%，它的计算宽度就是内容宽度（比如只有120px），padding: 10%就只有12px - 若 flex 容器本身是
fit-content或由内容撑开，它的“包含块宽度”可能远小于你预期 - 子项一旦设了
position: absolute，包含块就跳转到最近定位祖先，不再是 flex 容器
display: table-cell 里 padding 百分比完全无效
这不是浏览器兼容问题，而是 CSS2.1 规范明确定义的例外行为：
- 所有
padding百分比值被当作0处理，主流浏览器一致执行 - 如果你看到
padding-top: 20%没生效，别调样式，直接换display类型或改用固定像素值 - 想保持表格语义又需要比例内边距？得用 wrapper 元素套一层
div，再在 wrapper 上设padding
怎么验证当前 padding 百分比到底参照谁
别靠眼睛猜“看起来像不像”，用可测量方式定位包含块：
- 给疑似父容器加
border: 1px solid red和padding: 1px，拖动窗口观察子元素padding-top是否随该容器宽度线性变化 - 检查该容器是否设置了
position: relative、absolute或fixed——这会让子元素的包含块跳转到它身上 - 在 DevTools 的 Computed 面板看
padding-top的像素值，反向除以你怀疑的宽度，就能确认基准
真正容易被忽略的，是“包含块”未必等于“直接父元素”。遇到 padding 百分比异常时，第一反应不该是怀疑浏览器，而是打开 DevTools 逐层检查定位上下文和宽度来源——尤其是 position、display、flex、grid 这些会重定义包含块的属性。
