绝对定位的top、left百分比参照包含块的尺寸；top基于包含块高度，left基于宽度；margin百分比则始终基于包含块宽度，与transform的基准（自身尺寸）不同，混用易出错。
绝对定位的 top、left 百分比到底参照谁？
它参照的是**包含块（containing block）的尺寸**，不是父元素的 padding box，也不是 content box，更不是视口——只要父元素是定位上下文（即 position 为 relative、absolute、fixed 或 sticky），那它就是包含块；否则继续往上找，直到 body 或初始包含块。
常见错误现象：left: 50% 没把元素居中，反而偏右出界；或者 top: 100% 把元素“推”到父容器底部外一整屏——其实它真按父高 100% 算了，只是你忘了元素自身没设 transform: translateY(-100%) 之类修正。
- 如果父元素没设
position，left: 50%会相对于最近的定位祖先，可能跳过好几层 - 父元素若只有
width无height，且子元素用top: 50%，结果取决于父的 height 是否由内容撑开（常为 0，导致 top 实际为 0） -
padding和border不影响百分比计算——只看包含块的 width/height，不含内边距或边框
为什么 margin 百分比和 top/left 百分比行为不一致？
因为规范里就不是一回事：margin-top 和 margin-bottom 的百分比始终基于**包含块的 width**（不是 height！），而 top/left 是基于包含块对应轴的尺寸（top 看 height，left 看 width）。
这容易引发布局错觉。比如给一个高度固定的父容器设 margin-top: 20%，你以为是“高度的 20%”，实际是“父宽度的 20%”——如果父宽 400px，哪怕高只有 100px，margin-top 也是 80px。
立即学习“前端免费学习笔记（深入）”；
-
margin百分比在垂直方向也依赖 width，这是 CSS 历史遗留设计，无法绕过 -
top/bottom百分比可被transform: translateY()更可控地替代，尤其做垂直居中时 - Flex/Grid 布局下基本不需要靠百分比
top/left对齐，该换思路就换
transform: translate() 和 top/left 百分比混用的坑
两者百分比基准不同：top: 50% 是相对父高，transform: translateY(50%) 是相对**元素自身高度**。合起来用时，极易叠加出意料之外的偏移。
典型错误写法：top: 50%; transform: translateY(50%) —— 结果是“下移父高一半 + 再下移自己高一半”，远超预期。
- 要真居中：用
top: 50%; transform: translateY(-50%)，负号很关键 -
translateX(50%)和left: 50%同时设，等于横移父宽一半 + 自身宽一半，大概率跑偏 - 动画中混用静态偏移（
top）和变换（transform）可能触发重排，性能不如纯transform
移动端或缩放页面里，百分比偏移为啥忽大忽小？
不是 bug，是它真在算——只要包含块尺寸变了（比如 viewport 缩放、响应式断点切换、字体缩放影响行高进而撑开父高），top: 30% 就会实时重算。问题常出在“以为父容器高度固定”，实际它被 min-height、flex 或内容流悄悄改了。
调试建议：在 DevTools 里选中绝对定位元素，看右侧 computed 栏的 top 值是多少 px，再反推它的包含块 height 是多少——经常发现那个“父元素” height 是 0 或 auto，导致百分比失效。
- 用
height: 100vh代替height: 100%可控性略高，但注意vh在 iOS Safari 中有滚动条隐藏导致的动态变化问题 - 对高度敏感的场景，宁可用 JS 读取父
offsetHeight动态设top，也别赌百分比稳定 - CSS
contain: layout能限制包含块计算范围，但兼容性有限（Chrome 99+），别盲目加
