position: absolute 层级失效主因是父容器未形成定位上下文；其定位参照最近已定位祖先，z-index 作用域受限于层叠上下文，需避免魔数并用 getboundingclientrect() 替代 offsettop 精确定位。
position: absolute 为什么总盖不住目标元素
层级没生效，大概率是父容器没形成定位上下文。position: absolute 的“相对于谁”不是看 DOM 层级，而是看最近的「已定位祖先」（即 position 值为 relative、absolute、fixed 或 sticky 的祖先）。如果一路向上都没找到，就退化到初始包含块（通常是视口），这时 z-index 容易失效或错位。
- 检查目标元素的直接父容器是否设置了
position: relative（最常用且安全） - 避免在
position: static父容器里直接用z-index—— 它对static元素无效 - 多个绝对定位元素之间比层级，得确保它们共享同一个定位上下文，否则
z-index各算各的 - Chrome DevTools 里选中元素，看右侧面板的 “Computed” → “position” 和 “z-index”，确认是否被继承或重置
z-index 数值设多大才够用
不是越大越好，而是要理解层叠上下文（stacking context）的嵌套规则。一个新层叠上下文一旦建立（比如父元素有 opacity: 0.99、transform、filter 或非 auto 的 z-index），它的子元素的 z-index 就只在该上下文内比较，再大的数值也出不去。
- 引导层通常只需比目标区域高一级，例如目标容器
z-index: 10，引导弹层用z-index: 11即可 - 避免用
z-index: 9999这类魔数——它掩盖了真实层叠结构，后续加个 modal 就容易冲突 - 如果引导层被遮挡，先查父级是否意外触发了新层叠上下文（比如加了
will-change: transform） - 用
isolation: isolate可主动创建层叠上下文，但仅当明确需要隔离时才用
动态计算引导层位置时 offsetTop 总是不准
offsetTop 返回的是相对于**最近的已定位祖先**的偏移，不是相对于视口，也不是相对于 body。如果目标元素嵌套深、中间有 position: relative 的容器，offsetTop 就会层层累加，导致计算结果偏移。
- 更可靠的方式是用
getBoundingClientRect()，它始终返回相对于视口的坐标，不受祖先定位影响 - 注意：滚动时
getBoundingClientRect()结果实时变化，引导层需监听scroll或resize并重新定位 - 若目标元素本身有
transform，getBoundingClientRect()已自动包含其影响；但offsetTop/Left不包含 - 避免混合使用：不要用
getBoundingClientRect()算位置，又用offsetTop做判断逻辑
移动端 touch 事件下定位偏移或跟随失灵
CSS 定位本身没问题，问题常出在事件坐标与布局坐标的映射上。iOS Safari 和部分安卓 WebView 在高 DPR 屏幕下，clientX/clientY 是设备独立像素（DIP），而 getBoundingClientRect() 返回的是 CSS 像素，两者在缩放或 zoom 下可能不一致。
- 统一用
event.touches[0].clientX配合getBoundingClientRect()，别混用pageX（含滚动偏移） - 确保页面没有
viewport的user-scalable=yes，否则 pinch-zoom 会让定位彻底错乱 - 引导层若用
position: fixed，在 iOS Safari 滚动时可能出现渲染延迟，改用position: absolute+ 动态top/left更稳 - 真机调试时打开 Safari 的 “Show Paint Rects”，观察引导层是否被意外重绘或裁剪
动态布局引导真正的难点不在定位本身，而在「何时重算」和「谁该负责定位」——目标元素是否在动画中？是否由 JS 动态插入？这些都会让一次计算失效。别指望一套坐标用到底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
