padding-top/bottom百分比按包含块宽度而非父元素高度计算，是为了避免“高度依赖padding、padding又依赖高度”的循环依赖导致layout无法收敛；w3c规范强制其锚定包含块宽度以确保布局可解。
padding-top/bottom百分比为什么不能按父元素高度算
因为会触发浏览器 layout 阶段无法求解的循环依赖：一个 height: auto 的容器，其最终高度由内容 + padding 共同决定；而如果 padding-top: 50% 又反过来要基于这个“还没算出来的高度”去计算，整个布局就卡死——没有收敛解。
W3C CSS2.1 规范明确要求：padding-top 和 padding-bottom 的百分比值“must be calculated with respect to the width of the containing block”。这不是妥协，是唯一能保证每次 layout 都有确定起点的设计。
常见错误现象：
- 写了
padding-bottom: 56.25%却没撑开高度 → 父容器没设宽度（比如width: 100%或具体像素），导致包含块宽度为 0 - 在 flex 子项里写
padding-top: 20%，结果只有几像素 → 子项未设flex: 1或width: 100%，它的包含块宽度 = 内容撑开的窄宽度（如 120px），20% 就是 24px
包含块宽度 ≠ 父元素的 width 属性值
很多人以为“父元素设了 width: 300px，padding-bottom: 20% 就是 60px”，但实际基准是“包含块的宽度”，它可能和父元素的 width 属性不一致：
- 若父元素是
position: static普通块级元素，包含块通常是其最近块级祖先的内容区宽度（不含 padding/border） - 若父元素设了
position: relative，子元素设了position: absolute，那子元素的包含块就变成该 relative 父元素的 padding box 宽度（含 padding，不含 border） - 在 flex 或 grid 容器中，子项默认仍是 static 定位，所以它的包含块宽度 = flex/grid 容器的内容区宽度，不是它自己被分配到的尺寸
writing-mode 是唯一能改参考方向的合法方式
如果你真需要 padding 百分比按高度算，CSS 提供了标准出口：writing-mode: vertical-lr 或 vertical-rl。此时，原本的“上下”变成“左右”，padding-top 实际对应竖排文字的“行首侧”，其百分比就会基于包含块的 height 计算。
但代价明显：
-
margin的 collapse 行为从垂直方向移到水平方向 - 块级元素不再自动换行，水平方向无限延伸，容易溢出视口
- 所有依赖横排逻辑的组件（如按钮、表单控件）都需要重新适配
真实项目中极少用，除非做纯竖排阅读器或特定艺术排版。
为什么 margin-top/bottom 也按宽度算
margin-top 和 margin-bottom 的百分比同样锚定在包含块宽度，原因和 padding 一致：避免循环依赖。而且它和 padding 共享同一套计算逻辑，确保“横向留白和纵向留白数值相同时，视觉比例一致”——这是排版的基本需求。
容易忽略的关键点：
-
margin-top: 50%在position: absolute元素上，基准是其包含块宽度，不是自身高度，也不是父元素高度 - 不要试图用
margin-bottom: 100%来模拟“占满剩余高度”，它只会按宽度拉伸，和高度无关 - 现代替代方案更可靠：
vh单位（如padding-top: 10vh）直接基于视口，无循环风险，但注意 iOS Safari 地址栏收起时的重算抖动
真正复杂的地方不在规则本身，而在你打开开发者工具后，是否逐层检查了目标元素的“Computed”面板里的 containing block width 值——它往往和你以为的“父元素 width”根本不是一回事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
