移动端top百分比定位“看起来不准”是因为父容器高度为auto或过小导致30%计算结果极小；应改用vh单位、确保父容器有可计算高度，或检查iframe/shadow dom的包含块影响。
为什么移动端 top 百分比定位“看起来不准”
不是百分比写错了，也不是浏览器 bug，而是 top: 30% 的计算结果本身极小——因为它的参照物（父容器）高度太小或为 auto，导致 30% 算出来只有几像素。你拖动滚动条、切换横竖屏、甚至点开键盘后位置突变，都是这个原因在起作用。
检查父元素是否具备相对定位只是第一步，关键看它有没有“可算的高度”
加了 position: relative 不等于万事大吉。如果父容器没设 height 或 min-height，且内部没有内容撑开它，那它的 clientHeight 就是 0，top: 30% 自然解析为 0px。
- 用开发者工具选中父元素 →「Computed」→ 查看
height值：若显示auto且数值接近0，就是根源 - 别依赖
padding-top或margin-top“视觉撑高”，它们不参与百分比计算 - 在 iOS Safari 中，
height: 100vh可能因地址栏缩放产生渲染延迟，优先用min-height: 100vh - Flex/Grid 容器即使写了
align-items: center，也不会自动赋予自身可计算高度，仍需显式设高
移动端更稳的替代方案：用 vw/vh 直接锚定视口，绕过父容器高度陷阱
当你真正想表达“离顶部 10% 视口高度”，就别绕弯让浏览器去猜父容器有多高。直接用视口单位，语义清晰、计算确定、兼容性好（iOS 9.3+、Android 4.4+ 都支持）。
-
top: 10vh比top: 10%更可靠，尤其在父容器高度不可控时 - 避免混用：
top: calc(10vh + 20px)在旧安卓 WebView 中可能失效，优先拆解为纯单位 - 若需响应式微调，可用媒体查询配合
vh：@media (max-height: 600px) { top: 8vh; } - 注意：
vh在 iOS Safari 横屏时可能按初始视口计算，如有强一致性要求，需 JS 动态设置style.top
调试时最容易忽略的一点：iframe 和 Shadow DOM 会悄悄切换包含块
如果你的元素在 <iframe></iframe> 里，或位于 Web Component 的 Shadow Root 中，top: 30% 的参照物不再是外层 DOM 的 body，而是 iframe 的文档根或 Shadow Host 的盒模型——而它很可能没设定位、也没高度。
- 检查
offsetParent：在控制台运行document.querySelector('.my-el').offsetParent，看返回的是不是预期元素 - Shadow DOM 内部要确保宿主元素（host）有
position: relative且可计算高度 - iframe 场景下，
top: 30%是相对于 iframe 自身文档的body，不是父页面，这点常被当成“bug”排查半天
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
