CSS中margin-top百分比始终按包含块的宽度计算，与高度无关；常规流取最近块级祖先宽，绝对定位取首个非static祖先宽，fixed取视口宽，此举为避免循环依赖并统一计算模型。
因为这是W3C CSS2.1规范白纸黑字定的规则，不是浏览器bug，也不是历史遗留问题——它是刻意设计的稳定性保障。
margin-top: 10% 到底按谁的宽度算？
它永远按「包含块」（containing block）的 width 计算，和父元素的 height 完全无关。这个“包含块”不一定是直接父元素：
- 常规流中：通常是最近的块级祖先元素的
width -
position: absolute元素：按第一个非static定位的祖先（如relative或absolute父容器）的width -
position: fixed元素：按视口宽度（vw）算，不是vh - 找不到定位祖先时：退化为
html根元素的width
例如：.parent { width: 400px; height: 200px; }，子元素设 margin-top: 25% → 实际是 400px × 25% = 100px，不是 200px × 25% = 50px。
为什么不能按高度算？
不是忘了写，而是**不能**。核心原因有两个：
立即学习“前端免费学习笔记（深入）”；
-
避免循环依赖：如果
margin-top按父高算，而父高又由子内容撑开（子高 = 内容 +padding+margin），浏览器就得反复重排——先算 margin，再算父高，再重算 margin……最终可能无法收敛 -
保持计算模型统一：
margin-left和margin-right天然依赖宽度；把margin-top也拉到同一基准，布局引擎更简单、更可预测，开发者也不用记两套规则
这跟 top/bottom 百分比不同：top: 50% 确实按包含块的 height 算——但那是定位属性，和边距属于不同计算体系。
哪些场景最容易踩坑？
这些地方的 margin-top 百分比会明显违背直觉：
- 在窄高容器里写
margin-top: 50%想垂直居中 → 实际偏移量很小（按窄宽算），根本不到一半高度 - 响应式页面中，
body设margin-top: 10%→ 手机上几乎没留白（width小），桌面端却顶出大片空白（width大） - 嵌套多层
position: relative，误以为margin-top: 20%是按当前父级算 → 其实只认「第一个」非static祖先，中间层被跳过 - Flex/Grid 容器内设百分比
margin→ 它不参考网格轨道或 flex 项目尺寸，仍死守包含块的width
真正想按高度控制间距，别硬扛百分比：vh、calc()、gap（Flex/Grid）、或 transform: translateY() 都比赌 margin-top: X% 可靠。
最常被忽略的一点：这个规则对 padding-top 同样生效——它和 margin-top 共享同一套计算逻辑，不是特例，而是整个盒模型的底层契约。
