padding-top 百分比按包含块宽度而非父元素高度计算，因按高度计算会引发布局死循环；所有padding和margin的百分比均统一锚定包含块宽度，writing-mode可改变主轴使百分比按高度计算。
padding-top 百分比为什么不是按父元素高度算
因为会触发 layout 死循环。浏览器在计算高度时，如果 padding-top: 50% 依赖父元素当前高度，而父元素高度又由子元素内容 + padding 共同撑开（尤其当父元素 height: auto），就陷入“高度依赖 padding，padding 又依赖高度”的无限递归——根本无法收敛。宽度没这问题：块级元素默认占满父宽，内容超宽会换行，不会反向推高父容器宽度。
所有方向的 padding 百分比都统一锚定到包含块宽度
不只是 padding-top 和 padding-bottom，padding-left、padding-right 也一样；不只 padding，margin-top、margin-bottom 同样如此。W3C 规范强制统一基准，就是为了消除歧义和实现确定性布局。
-
padding: 20%→ 四边都是父容器宽度的 20% -
padding-top: 10%; padding-bottom: 15%→ 分别是父容器宽度的 10% 和 15%，和父容器高度无关 - 验证方法：在 DevTools 的 Computed 面板里看实际像素值，再除以你怀疑的“基准宽度”，结果应为对应百分比
容易被忽略的关键点：包含块 ≠ 直接父元素
真正决定百分比计算基准的，是“包含块”（containing block），它可能不是视觉上的直接父元素：
- 若父元素设置了
position: relative、absolute或fixed，它通常就是包含块 - 若父元素是
display: flex或display: grid容器，子项的包含块是该 flex/grid 容器的 content box 宽度 - 若子项设了
position: absolute，包含块会跳转到最近的定位祖先，不再是直接父元素 -
display: table-cell是明确例外：所有 padding 百分比被当作0处理，不是 bug，是规范行为
想让 padding 百分比按高度算？试试 writing-mode
这不是 hack，而是 CSS 规范支持的正经方案。把父容器设为 writing-mode: vertical-lr，书写流变成竖排，“上下”方向就变成了水平主轴，此时 padding-top 的百分比自动按父元素高度计算——因为百分比始终匹配当前主轴尺寸。但要注意：这会改变文本流向和布局逻辑，仅适用于明确需要该行为的特殊场景。
最常踩的坑，不是记不住“按宽度算”，而是忘了检查包含块到底是谁。看到 padding-top: 25% 没反应，第一反应不该是调样式，而是打开 DevTools，逐层看 position、display、transform 这些会劫持包含块的属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
