根本原因是定位参照系未立稳，必须给直接父容器设position: relative；优先用inset替代top/left，慎用vh，注意transform和overflow干扰。
绝对定位元素在不同分辨率下错位，根本原因不是单位选错了，而是定位参照系没立稳——top、left这些值永远在找“最近的已定位祖先”，找不到就 fallback 到 <html>，而它的尺寸和 margin 在各设备上并不一致。
必须给直接父容器加 position: relative
这是最常被跳过的一步。哪怕父容器视觉上“看起来没动”，只要它没显式声明 position: relative，absolute 子元素就会继续往上找。一旦落到 <body> 或 <html> 上，top: 10% 就变成相对于整个视口高度的 10%，而视口高度在 iOS Safari、横屏切换、地址栏显示/隐藏时都会变。
- 只对**直接父容器**设
position: relative，不要依赖祖父级或更上层 - 避免用
position: fixed作定位上下文——它脱离文档流，宽高不可靠，子元素百分比计算会失准 - 确认父容器有明确高度：如果仅靠内容撑开，且内容高度随分辨率变化（比如文字折行），那
top: 20%的基准就飘了
优先用 inset 替代单边 top/left
inset 是现代方案里最稳的替代：它不依赖“找祖先”，而是基于元素在正常文档流中的原始位置做偏移，天然避开定位上下文漂移问题。
- 写法更简洁：
inset: 5% auto auto 10%比top: 5%; right: auto; bottom: auto; left: 10%不易漏写 - 兼容性已覆盖 Chrome 87+、Firefox 63+、Safari 14.1+；旧版可用 PostCSS 自动展开
- 不适用于模态框遮罩层这类强覆盖需求——
inset仍需父容器提供布局空间，不能真正“压全屏”
慎用 vh，iOS Safari 下它会跳
vh 看起来很理想，但 iOS Safari 中地址栏显示/隐藏会导致视口高度突变，top: 20vh 可能瞬间上移或下坠。这不是 bug，是规范行为。
立即学习“前端免费学习笔记（深入）”；
- 临时解法：用 JS 动态计算并注入 CSS 变量
--vh，再在样式中用top: calc(var(--vh, 1vh) * 0.2) - 更可靠的做法：改用百分比 + 父容器固定比例高度（如
height: 100vh的父容器），让top: 20%相对于这个稳定容器 - 调试时打开 Chrome DevTools > Rendering > Layout Shift Regions，快速识别哪个元素在跳
别忽略 transform 和 overflow 的干扰
你以为在调 absolute 元素的位置，其实它早被裁掉了，或者坐标原点被悄悄挪动了。
- 父容器若含
transform: scale()（常见于 rem 适配方案），getBoundingClientRect()返回的坐标会失真，top: 50%实际可能偏移几十像素 - 父容器设了
overflow: hidden却没检查自身尺寸——先加outline: 1px solid red把所有盒子显形，确认是不是容器本身就被压缩或截断了 - 混合使用
top和transform: translate()时，两者的基准线不一致：前者基于 padding box，后者基于 border box，父容器有 padding 就容易错位
真正难调的从来不是该写 % 还是 vh，而是多个干扰源叠加后，你改了 top 却发现实际起效的是父容器的 transform 或 overflow 隐藏。动手前，先用开发者工具看清楚 Containing block 是谁，再决定动哪一层。
