CSS中padding/margin/top/bottom百分比统一锚定包含块宽度以避免循环依赖；width恒按包含块宽度，height仅在父有显式高度或absolute定位时有效；font-size百分比参照父元素，line-height参照自身。
因为CSS规范为避免布局循环依赖，强制将padding/margin/top/bottom的百分比统一锚定在包含块宽度上；而width/height/line-height等则按语义需求各自选择基准——这不是bug，是设计约束。
padding-top: 50% 为什么不是按父元素高度算
允许它按高度算会触发无法收敛的循环：一个height: auto容器的高度由内容 + padding-top共同决定，而padding-top: 50%又反过来依赖这个高度。浏览器layout阶段直接放弃解析。用包含块的width作唯一确定基准，能保证每次计算都有明确起点。
-
padding-top、padding-bottom、margin-top、margin-bottom全部基于包含块width，哪怕你写的是“top”或“bottom” - 只有
writing-mode: vertical-lr时，这些值才改按包含块height算 -
display: table-cell完全忽略padding百分比，视作0
width: 50% 和 height: 50% 的基准差异在哪
width始终参考包含块width，但height只在有明确高度上下文时才有效——比如父元素设了height、max-height，或子元素是position: absolute（此时参考包含块height）。
- 普通流中，若父元素
height未显式设置（如height: auto），height: 50%会被当作auto处理 -
position: absolute子元素的height: 50%参考的是其定位祖先（最近position: relative/absolute/fixed祖先）的height，不是父元素 -
font-size: 80%参考父元素font-size，line-height: 150%却参考自身font-size
怎么快速验证当前百分比到底参照谁
别靠眼睛猜“看起来像不像”，用可测量的方式定位包含块：
立即学习“前端免费学习笔记（深入）”；
- 给疑似父容器加
border: 1px solid red和padding: 1px，再观察子元素padding-top是否随该容器width变化线性缩放 - 检查该容器是否设置了
position: relative/absolute/fixed——这会让子元素的包含块跳转到最近的定位祖先 - 在DevTools的Computed面板里看
padding-top的像素值，反向除以你怀疑的基准宽度，就能确认它到底按谁算
真正容易被忽略的，是“包含块”未必等于“直接父元素”。当padding或margin百分比表现异常时，第一反应不该是怀疑浏览器bug，而是打开DevTools逐层检查定位上下文和宽度来源——尤其是position、display: flex、display: grid这些会重定义包含块的属性。
