百分比top的基准是包含块计算后的高度，而非视觉高度；若包含块高度为auto或0px，则top百分比失效，需确保父容器有明确高度和非static定位。
百分比top的基准是包含块高度，不是屏幕或父元素视觉高度
百分比 top 值（如 top: 30%）永远按「包含块」（containing block）的**计算后高度**来算，而不是你肉眼看到的父容器有多高、或者屏幕有多大。这个包含块，对 position: absolute 元素来说，就是它最近的、position 不为 static 的祖先（比如 position: relative）。但关键在于：如果那个祖先自身高度是 auto（例如只靠子元素 margin 或 padding 撑开），它的 computed height 可能只有几像素甚至 0px——那 top: 30% 算出来就是 0～10px，看起来就像“没动”。
- 用 DevTools 的 Computed 面板检查该祖先元素的
height，如果不是具体像素值（如400px），而是auto或0px，就是断点 - 常见诱因：父容器内全是
absolute子元素（不参与文档流）、用了float但没清除、或只设了padding-top: 5%（而 5% 的基准仍是 0） -
min-height: 100vh比height: 100%更可靠，后者依赖整条继承链上所有父级都设了高度
父容器没设 position: relative，top 就根本找不到参照
没有 position: relative（或其他非 static 值）的父容器，不会成为定位上下文。此时 top: 10% 会一路往上找，最终落到 body 或 html 上——而它们的高度随视口变化，导致同一行代码在 1920px 和 1366px 屏幕下表现完全不同。
- 必须显式写在你控制的 HTML 父节点上，不能依赖组件库 class 间接带出
- 不要用
position: fixed替代，它脱离文档流，宽高不可靠，且会创建新的包含块 - 临时验证方法：给疑似父容器加
outline: 2px solid red，再看absolute元素是否真的相对于它偏移
transform、filter 或 will-change 会悄悄替换定位基准
只要父元素设置了 transform（哪怕只是 transform: translateZ(0)）、filter 或 will-change，它就会成为新的包含块，且坐标系已被变形——top: 0 计算的是缩放/旋转后的内容区左上角，不是原始布局位置。这就是为什么加了 scale(0.8) 后，top: 0; left: 0 的元素看起来像“飘”进去了。
- DevTools 中检查
offsetParent，大概率指向那个带transform的祖先，而非你写的父容器 - 别试图用
transform: translate()补偿，成本高且易错；优先把absolute元素提级到无transform的干净祖先下 - 框架常悄悄加
translateZ(0)触发 GPU 加速，这也足以触发该问题
移动端和滚动容器里，高度基准更脆弱
移动端 top: 30% 错位，往往是因为 html 和 body 都没设高度，导致整个包含块链路从根就断了；滚动容器（overflow: auto）中，height 百分比只参照容器的固定高度，不是内容总高度，键盘弹出、地址栏收起、横竖屏切换都会让父容器高度波动，top: 30% 就跟着“飘”。
- 移动端必须同时写
html { height: 100%; }和body { height: 100%; }，中间所有父容器也得显式设高或min-height - 滚动容器里慎用
height: 100%+position: absolute，改用top/bottom控制区间（如top: 60px; bottom: 20px;）更稳定 - Safari 14–15.6 有个特殊坑：即使父级是
position: relative且height: 100vh，子元素height: 100%也可能被忽略，可加min-height: 0强制触发继承逻辑
真正麻烦的从来不是调不准数值，而是你根本不知道它正对着谁算。一旦父容器既浮动又没清空、还没设 position: relative，那它的定位行为就完全不可控。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
