绝对定位元素的top百分比基于包含块高度，而包含块是最近非static定位祖先，若其高度为auto且内容脱离文档流，则高度极小导致top计算值远低于预期。
top 百分比的基准确实是父级高度，但前提是那个“父级”必须是它的包含块（containing block），而这个包含块不一定是 DOM 上的直接父元素。
为什么 top: 30% 算出来只有几像素
常见现象：给子元素设 top: 30%，开发者工具里看到它只偏移了 5px 或 12px，远低于预期。这不是计算错误，而是它的包含块高度本身就很矮——比如 .planets-container 的 computed height 是 39px，那么 30% 就是 11.7px。
- 绝对定位元素（
position: absolute）的包含块，是最近的position不为static的祖先（如relative、fixed） - 这个祖先若没设
height或min-height，且内部全是脱离文档流的子项（如其他absolute元素），那它的高度就是auto，实际渲染接近 0 -
padding-top: 5%和margin-top: 300px都不会撑高包含块——前者参照的是自身宽度（不是高度），后者根本不参与高度计算
为什么检查 position: relative 还是不准
加了 position: relative 只是让该元素能成为包含块，不代表它就有了可计算的高度。很多开发者卡在这一步，以为“设了 relative 就万事大吉”。
- 用开发者工具选中该祖先元素 →「Computed」→ 查看
height：若显示auto且数值极小（如0px或39px），就是根源 - Flex/Grid 容器即使写了
align-items: center，也不会自动获得高度；必须显式加min-height: 100vh或height: 800px - iframe 或 Shadow DOM 内部的元素，其包含块是 iframe 文档根或 Shadow Host，而非外层 DOM；
offsetParent返回值可能出乎意料
更稳的替代写法：top 别依赖父高
当父容器高度不可控（比如内容动态、键盘弹出、横竖屏切换），硬推百分比链路极易失效。直接锚定视口更可靠。
立即学习“前端免费学习笔记（深入）”；
- 用
top: 10vh替代top: 10%：iOS 9.3+ / Android 4.4+ 全支持，语义明确，不受父容器塌陷影响 - 避免混用单位：
top: calc(10vh + 20px)在旧安卓 WebView 中可能解析失败；优先拆成纯vh或用媒体查询微调 - 强一致性要求下（如横屏时
vh按初始视口计算），需 JS 动态更新：el.style.top = window.innerHeight * 0.1 + 'px' - 对弹窗、悬浮层等场景，
top: 60px; bottom: 20px;比top: 30%; height: 50%更稳定，完全绕过高度继承链
真正容易被忽略的，是没打开开发者工具逐层点开看 computed height ——很多人在 CSS 里反复加 height: 100%，却没发现断点其实在第三层容器，或者被某个 transform 或 float 悄悄破坏了包含块资格。
