z-index失效主因是元素未进入层叠上下文；只有定位元素（relative/absolute/fixed/sticky）且父级未意外创建上下文（如opacity<1、transform不为none等）时，z-index才在同级生效。
z-index为什么设了没用
绝大多数 z-index 失效，根本不是写错了值，而是元素没进入「层叠上下文」——它就像一个独立的 Z 轴坐标系，z-index 只在自己的上下文里生效，跨上下文直接比不了。
典型现象：父容器加了 z-index: 999，子元素设 z-index: -1，结果还是盖在别的兄弟元素上；或者两个同级 div，一个设 z-index: 10，一个设 z-index: 1，但视觉顺序完全不按数字来。
- 只有定位元素（
position为relative、absolute、fixed或sticky）才能用z-index -
z-index: auto（默认值）不会创建层叠上下文，也不会参与同级比较 - 父元素一旦触发层叠上下文（比如加了
opacity: 0.99），它的所有子元素的z-index都只在它内部排序，不再和外部同级元素比
哪些属性会意外创建层叠上下文
除了显式设置 z-index（且值不为 auto）外，以下 CSS 属性只要一出现，就会让该元素变成层叠上下文根节点——这是最常被忽略的“隐形开关”：
-
opacity小于 1（哪怕opacity: 0.999） -
transform不为none（包括transform: translateZ(0)、scale(1)等看似无感的操作） -
filter不为none（哪怕filter: blur(0)） -
will-change设为transform、opacity等触发项 isolation: isolate-
mix-blend-mode不为normal
这些属性本身和层级无关，但浏览器为了实现效果必须新建渲染层，顺带就建了层叠上下文。调试时如果发现 z-index 突然不灵了，优先查父级有没有上述任意一条。
立即学习“前端免费学习笔记（深入）”；
如何检查当前元素是否处于同一层叠上下文
没有浏览器原生的“层叠上下文树”面板，但可以通过 DevTools 快速推断：
- 在 Elements 面板选中目标元素，看 Styles 侧边栏里
z-index是否显示为可编辑（灰色不可编辑 = 无效） - 展开 Computed 标签页，搜
stacking，看是否有stacking context: true（Chrome/Edge）或类似提示 - 临时删掉父元素的
transform、opacity等样式，观察层级是否恢复正常——这是最快验证法
注意：position: static 元素永远不属于任何层叠上下文，也永远不能设 z-index；而 position: relative + z-index: 0 是创建最小代价层叠上下文的常用手段（比加 transform 更轻量）。
真正需要跨上下文控制层级时怎么办
当必须让 A 元素（在上下文 X 内）盖过 B 元素（在上下文 Y 内），唯一的可靠办法是把它们拉到同一个层叠上下文里——通常意味着调整 DOM 结构或提升父级层级：
- 把 A 和 B 的共同祖先设为层叠上下文（例如加
position: relative; z-index: 0），再分别控制 A/B 的z-index - 避免在中间层加
opacity或transform，尤其不要加在 A/B 的直系父元素上 - 若使用
fixed或absolute定位，注意它们的包含块（containing block）可能已切换，此时z-index比较对象其实是包含块的层叠上下文根，而非视觉父级
最棘手的情况是第三方组件（比如弹窗库）内部自己创建了层叠上下文，又没暴露 z-index 控制入口——这时只能用更高层的全局上下文兜底，比如给 body 加 z-index，或用 :has() 选择器动态干预（需注意兼容性）。
