padding百分比严格相对于包含块的宽度计算，而非自身或父元素的宽高；此举避免高度与padding间的循环依赖，CSS规范强制统一锚定宽度基准。
padding 百分比是相对于包含块的宽度计算
不是相对于自身宽高，也不是父元素的 padding 或 content 区域，而是严格依据 containing block 的**宽度**（width）来算。这是 CSS 规范明确规定的，且对 padding-top、padding-bottom、padding-left、padding-right 全部生效——哪怕它们看起来“垂直”，也全看宽度。
- 如果父元素是 block 容器（如
div），且没有设置position，那么它的包含块通常是最近的块级祖先的内容区域宽度（不含 margin、border、padding） - 如果父元素设置了
position: absolute，则包含块是最近的position: relative/absolute/fixed/sticky祖先的 padding box 宽度（即含 padding，不含 border） -
padding-bottom: 50%在一个宽 200px 的容器里，结果就是 100px，哪怕这个元素自身高度只有 20px
为什么 padding-top/bottom 用宽度而不是高度？
这是为避免循环依赖。CSS 渲染时，高度常常依赖于内容或 padding，而 padding 若又依赖自身高度，就会陷入无法解析的死循环。用包含块宽度作为唯一确定值，能保证 layout 可解。
- 例如：一个
height: auto的 div，若允许padding-top: 50%相对自身高度，那高度又取决于 padding，padding 又取决于高度……浏览器直接拒解 - 所以规范强制统一锚定到包含块宽度，哪怕语义上“不直观”
- 这也解释了为什么
margin-top/margin-bottom百分比同样按包含块宽度计算
常见踩坑：flex / grid 容器中的包含块变化
在 flex 或 grid 子项中，包含块可能不是你直觉里的“父容器”，而是 flex/grid 容器的 content box 宽度——但前提是该子项未设置 position: absolute。一旦设了，包含块就跳转到最近的定位祖先。
- Flex item 默认
position: static，所以padding: 10%是按 flex 容器的宽度算，不是按它自己伸缩后的尺寸 - Grid item 同理；但如果 grid 容器本身宽度是
fit-content或由内容撑开，那包含块宽度可能比预期小得多 - 用
box-sizing: border-box不影响百分比基准，只改变最终尺寸是否含 border/padding
替代方案：需要基于高度做内边距怎么办？
纯 CSS 中没有 padding-bottom: 50vh 这种“相对自身高度”的合法写法。真要实现类似效果，得绕开百分比 padding：
立即学习“前端免费学习笔记（深入）”；
- 用
aspect-ratio+padding-bottom模拟（如aspect-ratio: 1 / 1配合固定宽，让宽高一致，再用 % padding） - 用伪元素 +
padding-top技巧（经典“响应式占位”：::before { content: ""; display: block; padding-top: 100%; }） - JS 动态读取
offsetHeight并设置style.paddingTop（适合复杂动态场景，但有重排风险）
最常被忽略的一点：包含块的宽度可能受 box-sizing、transform、writing-mode 影响——尤其是 writing-mode: vertical-rl 下，原本的 width 和 height 含义会互换，此时百分比 padding 的“宽度”基准也会跟着旋转。实际项目中遇到诡异百分比表现，先确认包含块是否被这些属性悄悄改写了。
