z-index无效主因是被层叠上下文限制：元素所在“楼”内比层级，而非全局比值；需用Chrome DevTools查Stacking Context定位“建楼”父级，并避免opacity
为什么 z-index 写了却没用？先看是否被层叠上下文锁死
z-index 不生效，90% 以上不是写错了数字，而是它所在的元素被包裹在某个「层叠上下文」里，导致它的层级只在那个小范围内有效。浏览器不是全局比 z-index 数值，而是按层叠上下文分组计算——就像两栋楼各自有 1～10 层，A 楼 10 层的人，依然可能被 B 楼 1 层的保安挡住门。
关键判断点：Chrome DevTools → Computed 面板 → 搜索 z-index，如果显示 auto，说明该元素未激活定位上下文；再搜 Stacking Context，若显示 “Yes”，就确认它已创建新上下文，且所有子元素的 z-index 都被限制在这个“楼”里。
- 常见无意识触发源：
transform: translateZ(0)、opacity: 0.99、filter: blur(1px)、will-change: transform - 哪怕父容器只写了
position: relative+z-index: 0，也会创建新上下文（注意：只写z-index不加position是无效的） -
isolation: isolate是唯一显式、可控的“建楼开关”，适合隔离模态框等强层级需求组件
哪些 CSS 属性会悄悄创建层叠上下文？
不是只有 z-index 才能建“楼”。很多性能优化或视觉效果相关的属性，会在你没意识到时强制创建新层叠上下文，从而切断子元素与外部的层级联系。
- 所有
transform值（包括translateX(0)、rotateY(0)、scale(1)）在 Chrome 56 及更早版本中必然触发；现代版虽放宽，但translateZ(0)仍被广泛误用为“硬件加速开关” -
opacity小于 1（哪怕opacity: 0.999） -
filter、clip-path、perspective、backdrop-filter -
contain: paint或contain: layout paint
特别注意：overflow: hidden 本身不创建层叠上下文，但它常和 position: relative 同时出现——而后者一旦配了 z-index，就成“楼”了。
立即学习“前端免费学习笔记（深入）”；
如何快速定位是哪个祖先元素在“建楼”？
打开 Chrome DevTools，选中出问题的元素，在 Computed 面板顶部搜索 Stacking Context。如果显示 “Yes”，说明它自己就是上下文根；如果显示 “No”，就往上逐级点父元素，直到找到第一个显示 “Yes” 的节点——那就是“楼”的入口。
更高效的方式是启用 Layers 面板（More Tools → Layers），它会用不同颜色区块直观标出每个层叠上下文的边界范围。鼠标悬停能看到该上下文的创建原因，比如 “transform on .carousel” 或 “opacity on .card”。
- 临时验证法：在 Elements 面板中，右键点击可疑父元素 →
Hide element，看层级是否恢复；或直接在 Styles 面板中勾选/取消transform、opacity等属性，观察变化 - 不要依赖“看起来没动”，
transform: rotateY(0deg)和transform: scale(1)同样触发上下文 - 移动端尤其要查
transform-style: preserve-3d，iOS Safari 对它的处理会让z-index完全失效
修复时该删属性还是调结构？
不能一概而论。删掉 transform 或 opacity 虽快，但可能破坏动画、透明效果或滚动性能；强行提高外部 z-index 更是徒劳——因为两个上下文之间比的是“楼高”，不是“楼层号”。
- 优先把需要高优展示的组件（如
.modal、.toast）挂到body下，脱离原有上下文链 - 若必须保留在原位置，用
isolation: isolate替代transform: translateZ(0)，前者只隔离不建新 Z 轴规则，后者却会重置整个堆叠逻辑 - Android 4.3 及以下 WebView 中，
translate3d(0,0,0)是渲染炸弹，需 UA 检测后降级为transform: translateX(0)或直接移除 - 涉及 3D 变换时，父子必须统一使用
translateZ()（而非混用translate3d()），且避免负值——旧 iOS 上translateZ(-1px)可能直接消失
最易被忽略的一点：层叠上下文的创建是“就近原则”，不是“最深原则”。哪怕 DOM 深度很深，只要离目标元素最近的那个父级触发了上下文，它就是容器。所以排查永远从目标元素开始向上，而不是从 body 往下猜。
