CSS中所有padding百分比均基于包含块宽度计算，这是为避免布局循环依赖的规范强制要求；flex子项padding:10%按flex容器content box宽度算，display:table-cell则忽略padding百分比。
因为CSS规范强制要求所有padding的百分比值——无论padding-top、padding-bottom还是padding-left、padding-right——都必须基于**包含块的宽度**计算，这是为避免布局循环依赖而做的底层约束，不是浏览器实现差异或历史遗留问题。
padding-top: 50% 为什么不是按父元素高度算
如果允许padding-top: 50%按自身或父元素高度计算，就会触发无法求解的循环：
- 一个
height: auto的容器，高度由内容 +padding共同决定 - 而
padding-top: 50%又反过来依赖这个高度 - 浏览器在layout阶段无法收敛，直接放弃解析
用包含块的width作唯一确定基准，能保证每次计算都有明确起点。这也是为什么margin-top: 50%同样按父宽算——它和padding共享同一套避免循环的设计逻辑。
flex子项里padding: 10%到底按谁的宽度算
默认情况下，它按**flex容器的content box宽度**算，而不是子项自己伸缩后的宽度。但这里有个关键陷阱：
- 如果flex容器本身宽度是
fit-content或由内容撑开，它的“包含块宽度”可能远小于你预期 - 子项若没设
flex: 1或width: 100%，它的计算宽度就是内容宽度（比如只有120px），padding: 10%就只有12px -
display: table-cell是明确例外：所有padding百分比被当作0处理，连计算都不走
怎么验证当前padding百分比到底参照谁
别靠眼睛猜“看起来像不像”，用可测量的方式定位包含块：
- 给疑似父容器加
border: 1px solid red和padding: 1px，再观察子元素padding-top是否随该容器width变化线性缩放 - 检查该容器是否设置了
position: relative/absolute/fixed——这会改变子元素的包含块，使其跳转到最近的定位祖先 - 在DevTools中查看Computed面板里的
padding-top值，它已换算成像素，反向推导即可确认基准
真正容易被忽略的，是“包含块”未必等于“直接父元素”。当遇到padding百分比表现异常时，第一反应不该是怀疑浏览器bug，而是打开DevTools逐层检查定位上下文和宽度来源——尤其是position、display、flex/grid这些会重定义包含块的属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
