百分比top/left的基准是包含块而非父元素：absolute/fixed下按包含块高度/宽度计算，relative下则按自身高度/宽度计算，且包含块需为最近的非static定位祖先或视口。
百分比 top/left 的基准不是父元素，而是包含块
写 top: 20% 时，浏览器根本不管你的“父元素”有没有设 height，它只找最近的「已定位祖先」（position: relative/absolute/fixed/sticky）作为包含块。如果没找到，就 fallback 到初始包含块（通常是视口）。这意味着：你看到的“父元素”，很可能根本不是定位基准。
常见错误现象：
- 给子元素写
top: 50%，结果贴在页面顶部——因为父容器没加position: relative，定位基准跑到了<body>或视口 - 嵌套多层 Flex 容器，只在外层加了
relative，中间某层却意外写了transform: scale(1)，它成了新的包含块，导致偏移突变 - 父容器有
padding-top: 30px，但top: 0的元素离可视区域顶部就是 30px——因为top是从包含块的 content box 上边缘起算，不是 border box
父容器高度为 auto 时，top 百分比直接失效
top: 20% 的意思是“取包含块高度的 20%”，但如果包含块本身高度是 auto（靠内容撑开），而内容又全是绝对定位子项（不参与布局），那它的计算高度就是 0 → 20% × 0 = 0。此时 top: 20% 等价于 top: 0，但你完全看不出哪里错了。
使用场景中必须确认：
立即学习“前端免费学习笔记（深入）”；
- 包含块是否显式设置了
height、min-height或max-height - 如果用
vh，注意 iOS Safari 地址栏收放会触发视口高度跳变，top: 20vh可能瞬间上移 - 更稳的做法是让包含块固定比例：
height: 100vh+padding-bottom: 100%（配合position: relative），再用top: 20%，这样基准始终存在
left 和 top 的百分比基准不同，且互不影响
left: 20% 是相对于包含块的**宽度**，top: 20% 是相对于包含块的**高度**。两者没有几何关联，只是碰巧都叫“20%”。所以：
- 当包含块宽高比变化（比如响应式时从 16:9 变成 4:3），
left: 20%; top: 20%的元素不会保持在对角线上，而是会“滑出”预设路径 - 想模拟对角线布局，不能只依赖百分比，得配合
transform: translate(-50%, -50%)或改用inset+ 固定比例容器 - 用
inset: 10% auto auto 10%比top: 10%; left: 10%更可控——它基于元素在正常流中的原始位置推算，不依赖包含块高度是否可算
transform 和 overflow 会悄悄改写包含块定义
哪怕只是给父容器加了 transform: translateZ(0) 或 will-change: transform，它就会变成新的包含块。这不是 bug，是规范行为。更隐蔽的是 overflow: hidden 本身不创建包含块，但如果它和 transform 同时存在，就可能触发层叠上下文变更，间接影响 offsetParent。
调试建议：
- 在 Chrome DevTools 中选中元素 → Elements 面板右键 → “Scroll into view”，再看右下角显示的
offsetParent是谁 - 临时删掉所有
transform相关声明，观察定位是否回归预期 - 避免在定位上下文容器上滥用
transform，尤其不要只为了开启硬件加速而加translateZ(0)
transform 激活、也可能因 iOS 地址栏收放而瞬时切换。调一个 top 值前，先确认 offsetParent 是谁，比反复改 CSS 更省时间。 
