z-index无效是因为只对已定位元素生效，且受层叠上下文限制；父元素设置opacity、filter等会创建新层叠上下文，使子元素z-index被“锁死”在内部。
z-index 为什么加了也没用
因为 z-index 只对已定位元素（position 为 relative、absolute、fixed 或 sticky）生效，且只在**同一个层叠上下文**内比较。你给子元素设了 z-index: 9999，但它的父容器设置了 opacity: 0.99 或 transform: translateZ(0)，就会创建新层叠上下文——子元素的 z-index 就被“锁死”在该父级内部，根本出不去。
常见错误现象：
- 开发者工具里看到元素
z-index计算值是auto，说明它没被当作层叠上下文内的可排序元素 - 遮挡它的元素明明
z-index: 10，而它自己是z-index: 20，却还是被盖住 - 删掉父级一个
filter: blur(1px)，遮挡立刻消失
怎么快速定位哪个父级在“截胡”z-index
打开 Chrome DevTools，选中被遮挡的元素，在右侧面板的 Computed 标签页里搜 stacking context。如果显示 “This element establishes a stacking context”，说明它自己就是边界；再往上逐级点父节点，找到第一个标有该提示的祖先，就是问题源头。
实操建议：
- 临时删掉父级的
opacity、filter、transform、will-change等可疑样式，看遮挡是否消失 - 把目标元素剪切出来，临时挂到
下，验证是否真由层叠上下文导致 - 避免对父级滥用
will-change: transform，它比transform更容易隐式创建层叠上下文
fixed/absolute 元素被父容器 overflow 遮住怎么办
overflow: hidden（或 auto、scroll）会直接裁剪脱离文档流的子元素，此时 z-index 完全无效——裁剪发生在绘制前，层叠顺序还没开始算。
实操建议：
- 检查父容器是否真需要
overflow: hidden；如果只是为了清除浮动，改用display: flow-root更安全 - 若必须保留
overflow，把定位元素移出该父容器 DOM，挂到更高层级（比如document.body），再用 JS 动态计算位置 - 极少数场景可用
overflow: clip（Chrome 119+），但它不解决层叠问题，也不能替代z-index的语义
DOM 位置和 z-index 数值哪个更重要
多个 position: fixed 元素之间，HTML 顺序决定默认层叠：后写的元素天然在前写的上方（前提是同属根层叠上下文）。所以 z-index: 100 写在 HTML 前面的元素，可能被后面一个 z-index: 10 的元素盖住。
实操建议：
- 把关键 fixed 元素（如顶部导航、底部栏、全局弹窗）放在 HTML 文档末尾，紧邻
- 统一用 CSS 自定义属性管理层级，例如
--z-topbar: 1000、--z-modal: 2000，避免硬编码999999 - 别只盯着数字大小——
.parent { z-index: 10 }下的.child { z-index: 999 }永远赢不了同级的.sibling { z-index: 11 }
z-index，其实都在某个盒子里算数；真正要动的，往往是那个盒子的边框。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
