CSS规范强制padding百分比（含top/bottom）统一按包含块宽度计算，以避免“高度依赖padding、padding又依赖高度”的循环依赖；包含块未必是直接父元素，需用DevTools验证。
因为浏览器 layout 阶段必须避免“高度依赖 padding，padding 又依赖高度”的死循环，所以 CSS 规范强制所有 padding 百分比（包括 padding-top、padding-bottom）统一按包含块宽度计算——这不是 bug，是唯一能保证布局收敛的设计约束。
padding-top: 50% 为什么不能按父元素高度算
如果允许它按父元素高度计算，就会触发无法求解的循环：
- 父元素
height: auto，高度由子内容 +padding-top共同决定 - 而
padding-top: 50%又反过来依赖这个尚未确定的高度 - 浏览器 layout 阶段直接放弃解析，结果不可预测
宽度则不存在这个问题：父元素宽度通常由上层容器明确给出，不会反向依赖子元素。
“父元素”不等于“包含块”，这是最常踩的坑
实际计算基准是“包含块宽度”，而它未必是你写的直接父元素：
- 普通
div嵌套中，包含块通常是最近块级祖先的内容区宽度（不含border/padding） - 若父元素设了
position: relative，子元素又用了position: absolute，那包含块就跳转到该relative父元素的padding-box宽度（含padding，不含border） -
display: flex或display: grid容器中，子项的包含块宽度 = 容器的 content box 宽度，不是子项自己被分配到的尺寸
验证方法：在 DevTools 的 Computed 面板看 padding-top 的像素值，再除以你怀疑的宽度，就能反向确认基准。
display: table-cell 是明确例外
display: table-cell 下所有 padding 百分比都被当作 0 处理，主流浏览器一致执行。这不是渲染 bug，是 CSS2.1 规范白纸黑字写的例外行为。
- 如果你看到
padding-top: 20%在table-cell里没生效，别调样式 - 要么换
display类型（比如改用inline-block），要么直接写固定像素值
真正容易被忽略的，是“包含块”这个概念本身——它由 position、display、float 等属性共同决定，不是 DOM 树里的父子关系能直接推断出来的。遇到百分比异常，第一反应不该是查文档或换浏览器，而是打开 DevTools，一层层点开父级的 computed styles，看它的 position 和 display，再定位到真正的包含块宽度来源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
