padding-top/bottom百分比按包含块宽度计算，而非高度，是为了避免layout循环依赖；css规范强制统一锚定宽度基准以确保布局可解。
padding-top/bottom 的百分比为什么不是按父元素高度算
因为 CSS 规范明确禁止用自身或父元素高度作为 padding 百分比的计算基准——否则会触发 layout 循环。比如一个 height: auto 的容器，若 padding-top: 50% 按自身高度算，那它的高度又依赖于 padding，padding 又依赖于高度……浏览器无法求解。
所以规范强制统一锚定到包含块的 width：它是个确定值，不随子内容变化而动态反馈，layout 过程可收敛。
这不是“设计失误”，而是排版模型底层约束。你看到的“反直觉”，其实是为避免不可解布局而做的必要取舍。
flex 子项里 padding: 10% 到底按谁的宽度算
按它自己的计算宽度（computed width），不是 flex 容器的宽度。
这和很多人直觉相反：给一个 display: flex 的父容器设了 width: 800px，子项却只写了 padding: 10%，结果 padding 小得看不见——因为子项默认是 flex: 0 1 auto，它的宽度由内容决定，可能只有 120px，10% 就是 12px。
要让它真正按父容器宽度响应，得先让子项“占满”：
- 加
flex: 1，让子项分配到 flex 容器的可用宽度 - 或显式写
width: 100%（需确保父 flex 容器有明确 width） - 别依赖
justify-content或align-items来“撑开” padding 计算基准
table-cell 元素为什么 padding 百分比完全无效
display: table-cell 是 CSS 2.1 明确规定的例外：它的 padding 百分比值被当作 0 处理，所有主流浏览器都一致执行该行为。
这不是 bug，是规范硬性限制。常见错误现象包括：
- 给
<td> 或设置了 <code>display: table-cell的<div> 加 <code>padding: 5%，毫无反应 - 反复检查父宽、box-sizing、是否塌陷，最后才发现 display 类型卡死
- 改用固定单位，如
padding: 0.75em或padding: 12px - 外层套一层
div，把百分比 padding 放在外层，cell 只负责对齐和内容渲染 - 用
margin-top模拟——但它同样按父 width 算，且会脱离文档流影响其他元素 - 靠 JS 动态计算并写内联 style——增加维护成本，SSR/SEO 不友好
- 误用
aspect-ratio+padding-bottom拼凑——仅适用于宽高比固定的场景，不能通用
替代方案只有两个：
想让 padding 基于高度怎么办：别硬刚百分比
CSS 中没有合法的 padding-bottom: 50vh 或 padding-top: 50%（相对自身高度）。所有试图绕过规范的 hack 都不稳定，比如：
真正可行的路径是换思路：用 vh/vmin 替代百分比，或用 calc() 配合自定义属性做近似控制；如果必须等比缩放且依赖高度，优先考虑用伪元素 + position: absolute 撑开空间，而不是强求 padding 服从高度。
最常被忽略的一点：很多你以为“需要基于高度”的需求，其实本质是「需要垂直居中」或「需要固定宽高比容器」——直接解决那个目标，比硬改 padding 基准更可靠。
