margin-top: 10% 按父元素的宽度（width）计算，与父元素高度无关；绝对定位元素则按最近非static祖先的宽度计算；该规则源于css规范为避免循环依赖和提升渲染稳定性而统一设定。
margin-top: 10% 到底是按谁的高度或宽度算的
它按父元素的 width 算，和父元素的 height 完全无关。哪怕你写的是 margin-top 或 margin-bottom，浏览器也只看父容器的宽度值。
常见错误现象：
- 在高度远大于宽度的容器里设
margin-top: 50%，结果元素离顶部很近（因为按窄宽算） - 用
margin-top: 50%尝试垂直居中，永远失败——它不是基于父高，不构成“一半高度” - 全屏布局中
body上设margin-top: 10%，在手机上几乎看不见留白，在宽屏上却顶出一大块空白
根本原因：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 百分比怎么算
它不再看父元素，而是看“第一个非 static 定位的祖先”的宽度。
使用场景：
-
position: absolute子元素，其margin-top: 20%基于最近的relative/absolute父容器的width -
position: fixed元素，margin百分比始终相对于视口宽度（vw），不是document高度 - 如果找不到定位祖先，就退化为根元素（
html）的宽度
容易踩的坑：
- 误以为
top: 50%和margin-top: 50%基准一致——其实top是按包含块高度算，margin-top按宽度算，完全两套逻辑 - 嵌套多层
relative容器时，没意识到margin百分比只认“第一个”，跳过中间未定位层
为什么设计成“全按宽度算”，而不是上下/左右分开基准
这不是疏忽，是刻意为之的稳定性妥协。
核心理由有两个：
- 避免循环依赖：高度常由内容、行高、margin 反推；若
margin-top: 10%又要依赖父高，渲染引擎可能陷入“先要高→先要 margin→先要高”的死锁 - 保证计算可预测：宽度在大多数布局阶段（如块格式化上下文建立时）已确定，更稳定可靠
性能影响：
- 浏览器无需在 layout 阶段反复回溯高度，提升首次渲染速度
- 响应式重排时，只要父宽变，所有百分比
margin可一次性重新计算，无副作用
padding-bottom 实现正方形时，为什么能“骗过”这个规则
正是因为它也按父宽算，才让这个技巧成立——padding-bottom: 100% = 父宽 × 100%，撑出来的高度恰好等于 width: 100% 的宽度。
但要注意边界条件：
- 必须配合
height: 0或overflow: hidden，否则内容会把高度撑开，破坏比例 - 父容器不能是
display: inline或无明确宽度（比如仅靠fit-content），否则百分比失去参照 - Flex/Grid 子项中该技巧依然有效，因为它们的
padding百分比仍遵循同一规则：相对于 flex container / grid container 的宽度
真正容易被忽略的点：这个“宽度基准”规则对 margin、padding、width、height（当设为百分比时）全部统一适用，但 top/bottom/transform: translateY() 各自另有一套基准逻辑，混用前务必确认清楚。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
