padding百分比始终以父元素宽度为基准，而非自身宽高或父元素高度；用于响应式正方形、等比内边距等场景，需配合绝对定位避免内容被挤出。
padding百分比为什么不是按自身宽高算的
因为CSS规范里明确写了：padding（包括padding-top、padding-bottom等）的百分比值，基准永远是**父元素的宽度**，不是当前元素自身的宽或高，也不是父元素的高度。这个规则对所有方向都一样，哪怕你写的是padding-top: 20%，它照样按父容器宽度的20%来算。
常见错误现象：
— 给一个高度远大于宽度的子元素设padding-top: 50%，结果padding大得离谱；
— 以为padding-bottom会按父元素高度算，结果发现高度没变但padding撑开了整个块；
— 在flex或grid容器里改了父元素尺寸逻辑，却忘了padding百分比仍死守“父宽”这条线。
使用场景：
— 做响应式正方形卡片（配合height: 0; padding-bottom: 100%这种hack）；
— 需要padding随屏幕宽度线性缩放，又不想用JS监听resize；
— 实现等比例内边距的图片容器（比如封面图上下留白固定比例）。
padding-bottom实现正方形容器时怎么避免内容被挤掉
靠padding-bottom撑高，但内容会没地方放——这是最常卡住的地方。关键不是“加padding”，而是“把内容从流中抽出来”，否则padding一加，内容就往下掉，甚至溢出。
立即学习“前端免费学习笔记（深入）”；
实操建议：
— 父容器设position: relative；
— 子内容（比如img或div）设position: absolute; top: 0; left: 0; width: 100%; height: 100%；
— 父容器自身不设height，只靠padding-bottom撑开；
— 如果需要文字居中，别用line-height，改用display: flex; align-items: center; justify-content: center（注意：flex需作用在绝对定位的子容器上，或另套一层）。
性能影响：纯CSS方案无重排开销，但要注意position: absolute会让子元素脱离文档流，父容器无法自动适应内容高度（这本来就是你要的效果，所以不算坑，只是得心里有数）。
vertical-align和padding百分比能一起用吗
不能直接互换用途。vertical-align只对inline-level元素（如img、span）或table-cell生效，而padding百分比是盒模型层级的，两者作用域不同。有人想用vertical-align: middle配padding-top: 25%来“模拟”垂直居中，结果发现根本对不上——因为padding-top还是按父宽算的，跟垂直方向毫无关系。
容易踩的坑：
— 在inline-block容器里设padding-top: 30%，以为能推高内部文字，结果整块被横向撑宽；
— 把vertical-align写在块级元素上（比如div），完全无效，还误以为是padding没起作用；
— 混用line-height和padding百分比做垂直居中，在响应式下出现文字错位。
Flex/Grid布局下padding百分比还可靠吗
可靠，但基准没变——仍然是父元素的**宽度**，哪怕父元素是flex item或grid cell。这点特别容易误解：以为“父元素被flex压缩了，padding百分比也会跟着缩”，其实不会。只要父元素有明确宽度（哪怕是flex-basis计算出来的），padding百分比就照算不误。
需要注意：
— 如果父元素宽度为auto（比如未设flex-basis且内容很短），那百分比padding会按0算，结果padding=0；
— Grid中若父项设了grid-template-columns: 1fr，它的宽度由网格轨道决定，padding百分比就按那个轨道宽度算；
— Safari旧版本对flex容器内百分比padding有渲染延迟，极少数情况需加min-width: 0触发重算。
真正复杂的地方在于：你得时刻分清“谁是父元素”——嵌套多层flex/grid时，很容易看错padding的参照物。一眼扫过去以为是祖父容器，实际是直接父级。这个层级关系一旦搞混，数值就全乱了。
