CSS中margin-top百分比始终基于父容器宽度计算，而非高度；top百分比则基于包含块高度，二者基准不同，这是W3C规范明确规定的稳定性设计。
top/left 百分比和 margin 百分比根本不是一回事
很多人以为 top: 20% 和 margin-top: 20% 都是“按父容器某个尺寸的 20%”，其实它们参照的基准完全不同：top 看父容器的 height，margin-top 却强制看父容器的 width——哪怕你写的是垂直方向。这不是浏览器 bug，是 W3C CSS2.1 规范第 8.3 节白纸黑字定的：*“The percentage is calculated with respect to the width of the containing block, even for ‘margin-top’ and ‘margin-bottom’.”*
常见错误现象：
-
margin-top: 50%想垂直居中，结果在窄屏上偏得离谱（因为按父宽算，不是父高） - 全屏布局里给
body设margin-top: 10%，手机上看几乎没留白，宽屏却顶出大片空白 - 误用
top: 50%+margin-top: -50%想抵消，结果叠加错乱（一个按高，一个按宽）
绝对定位元素的百分比偏移到底参照谁
top: 20% 或 left: 30% 的百分比，永远基于「包含块（containing block）」的对应尺寸：top 和 bottom 看包含块的 height，left 和 right 看 width。而这个包含块，**不一定是直接父元素**，而是最近的已定位祖先（position: relative/absolute/fixed/sticky）。如果父元素没设 position: relative，它就不是包含块，浏览器会继续往上找，甚至落到 html 或视口。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 父元素只写了
width: 100%但没设height，此时top: 50%的 50% 是 0（因为 computed height 是 auto） - 嵌套多层 flex 容器，中间某层漏了
position: relative，导致top实际参照的是更外层容器 - 父容器用了
transform: translateY()，会偏移其 padding box 起点，让top的计算原点悄悄移动
为什么设计成“margin 全按 width 算”
这不是历史遗留的疏忽，而是刻意选择的稳定性妥协。如果 margin-top: 50% 按父高算，而父高又由子元素内容（含 margin）决定，就会出现循环依赖：要算 margin → 得先知道父高 → 父高又依赖 margin → 死锁。统一按 width 算，能避免这种无法解析的布局链。
实际影响：
-
padding-top: 50%、padding-bottom: 50%同样按父宽算，和 margin 规则一致 - 在响应式布局中，
margin-top: 10%会随屏幕宽度线性变化，但和视觉上的“垂直间距感”常不匹配 - 想真正控制垂直间距比例，得用
inset（现代属性）或改用transform: translateY()（基于自身尺寸）
真正可控的垂直居中怎么做
靠 top: 50% + margin-top: -XXpx 或 margin-top: -50% 都不可靠。最稳的组合是：
top: 50%; left: 50%; transform: translate(-50%, -50%);
这里 top: 50% 把元素上边缘放到父容器高度一半的位置，transform: translateY(-50%) 再把自己向上拉回自身高度的一半——两个百分比基准不同（前者看父高，后者看自身高），但配合起来刚好抵消偏差。
注意：
- 别写成
top: 50%; transform: translateY(50%)，那是双倍下移 - 如果父容器高度是 auto（比如由 flex 内容撑开），先确认 computed height 是否有效，否则
top: 50%就是 0 - 移动端 Safari 对
height: 100vh+ 百分比定位有渲染延迟，建议换min-height: 100vh
