z-index: 9999 无效的主因是元素未定位或被父级层叠上下文隔离；需确认 position 非 static，且祖先无 opacity/transform/filter 等触发新层叠上下文的属性。
z-index: 9999 没被遮挡，而是压根没参与层叠计算——它要么没定位，要么被父级“关进小房间”了。
元素 position 还是 static，z-index 就是废代码
浏览器只对 position 为 relative、absolute、fixed 或 sticky 的元素应用 z-index。默认的 static 下，哪怕你写 z-index: 2147483647，DevTools 的 «Computed» 面板里 z-index 也显示为 auto，position 仍是 static。
- 用 Chrome DevTools 选中该元素，在 «Computed» 面板搜
position，确认计算值不是static - 临时加
position: relative（不位移、不影响布局），如果遮挡立刻消失，问题就坐实了 - 响应式场景下容易漏：桌面端写了
position: fixed，移动端媒体查询里没补，退成static，z-index彻底失效
父级用了 opacity/transform/filter，等于给子元素建了玻璃罩
只要任意一个祖先元素（不一定是直接父级）触发了层叠上下文，整个子树就被锁死在独立空间里。z-index: 9999 只能跟同房间里的兄弟比，够不到外面的导航栏或弹窗。
- 触发层叠上下文的常见属性：
opacity: 0.99、transform: translateZ(0)、filter: blur(0)、will-change: transform、isolation: isolate、position: fixed且z-index不为auto - 在 DevTools 中选中被遮挡元素 → «Layout» 标签页看
Stacking context是否为Yes；点击 «Show stacking context» 高亮边界 - 逐级点父节点，在 «Computed» 里搜
transform、opacity、filter，第一个非默认值就是源头
z-index 数值再大，也突破不了父容器的“天花板”
子元素的 z-index 只决定它在父容器内部的顺序，对外它只继承父容器在整个页面中的层级位置。比如父容器 z-index: 10，子元素写 z-index: 9999，它依然压不过另一个 z-index: 20 的同级容器。
立即学习“前端免费学习笔记（深入）”；
- 修复方向不是堆数字，而是提升“关住它”的那个父容器本身的
z-index（例如设为z-index: 1050） - 如果父容器必须保留
transform（如动画需要），就给它同步加position: relative和足够高的z-index - 验证是否真由层叠上下文导致：用 JS 把目标元素（比如弹窗）剪切出来，
document.body.append()，再看是否正常显示
z-index: 0 比 z-index: auto 更危险
很多人以为 z-index: 0 很安全，其实它会强制创建新层叠上下文；而 z-index: auto（默认值）不会——前提是元素已定位。一个 position: relative; z-index: 0 的父容器，等于主动给子元素建了个“结界”。
- 检查父容器是否意外设置了
position: relative+z-index: 0 - 若只是想让父容器参与层叠排序但不隔离上下文，保留
z-index: auto更稳妥 -
overflow: hidden、auto或scroll的父容器会裁剪子元素，z-index根本没机会起作用
真正卡住人的从来不是数字大小，而是哪一层 DOM 节点悄悄建了上下文、哪一行 CSS 覆盖了 position、哪个媒体查询漏掉了定位声明——这些细节在 DevTools 里都看得见，但得主动去查，不能靠猜。
