z-index 失效的直接原因是元素未创建层叠上下文；只有满足 position+非auto z-index、opacity<1、transform≠none 等条件之一时，元素才创建新层叠上下文，其子元素的 z-index 才在此上下文中生效。

z-index 为什么在 style 里写了却没用？

直接原因：该元素没创建层叠上下文（stacking context），z-index 自然不生效。它不是“写上就起作用”的 CSS 属性，而是依赖父级层叠上下文的存在和自身是否满足触发条件。

哪些情况会强制创建层叠上下文？

只有当元素满足以下任一条件时，它才会成为层叠上下文的“根”，其子元素的 z-index 才能在这个新上下文中起作用：

• position 值为 absolute、relative、fixed 或 sticky，且同时设置了 z-index 为非 auto 值（如 0、1）
• opacity 小于 1（例如 opacity: 0.99）
• transform 不为 none（例如 transform: translateZ(0)、scale(1)）
• filter 不为 none（例如 filter: blur(0)）
• will-change 指定了会触发合成的属性（如 will-change: transform）
• isolation 设为 isolate
• mix-blend-mode 不为 normal

常见踩坑：父容器“静默劫持”了 z-index

即使你给目标元素设了 z-index: 999，如果它的某个祖先元素（不一定是直接父级）已创建了层叠上下文，且该祖先的 z-index 值较低，那么整个子树都会被“压”在下面——子元素再高的 z-index 也突破不了这个祖先的层叠层级。

典型表现：

• 弹窗 z-index: 9999 却被一个 z-index: 10 的导航栏盖住
• 明明加了 position: relative 和 z-index: 1，但兄弟元素依然盖在上面
• 用 transform: translateZ(0) 强制提升后，突然发现其他动画错位或模糊

排查建议：打开浏览器开发者工具 → 选中元素 → 查看 Computed 标签页 → 搜索 stacking context 是否标记为 true；再逐级向上检查祖先是否有意外创建上下文的样式。

最稳妥的调试方式：从根开始控制层叠流

不要只盯着目标元素加 z-index，要梳理整条 DOM 路径上的层叠上下文链：

• 确保目标元素的**最近层叠上下文祖先**（通常是父容器）本身有合理的 z-index，且未被更外层压制
• 避免在无关容器上滥用 opacity、transform 等隐式创建上下文的属性
• 如需强干预，可在关键容器上显式设置 isolation: isolate，让它成为独立上下文边界
• 移动端尤其注意：某些安卓 WebView 对 transform 创建上下文更敏感，translateZ(0) 可能引发重绘异常

层叠上下文不是开关，是嵌套的“盒子套盒子”。真正难的不是写 z-index，而是看清当前在哪一层盒子里操作。