z-index失效是因为它只对已定位元素生效，且仅在同一个层叠上下文中比较；若祖先元素设置了opacity、transform等属性创建了新层叠上下文，子元素的z-index就被限制在该上下文中无法越级。
z-index 为什么加了还是被盖住
因为 z-index 只对已定位元素生效，且只在**同一个层叠上下文**里比较大小。你给子元素设了 z-index: 9999，但它的某个祖先（不一定是父级）设置了 opacity: 0.99、transform: scale(1)、filter: blur(0) 或 will-change: transform，就会创建新层叠上下文——子元素的 z-index 就被“锁死”在里面，根本出不去。
常见现象包括：
-
z-index在 DevTools 的 Computed 面板里显示为auto或not applicable - 遮挡它的元素明明
z-index: 10，自己是z-index: 20，却仍被压 - 删掉父级一行
filter: blur(1px)，遮挡立刻消失
怎么快速定位哪个祖先在“建结界”
打开 Chrome DevTools，选中被遮挡的元素，在右侧面板的 Computed 标签页里搜索 stacking context。如果某节点显示 This element establishes a stacking context，它就是边界；再往上逐级点父节点，找到第一个标有该提示的祖先，就是问题源头。
更直观的方式是打开 Rendering 面板 → 勾选 Show layers panel，在 Layers 面板里直接看到每个层叠上下文节点，点一下就能高亮对应 DOM 元素。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 临时注释掉疑似父级的
opacity、transform、filter、will-change等样式，看遮挡是否消失 - 把目标元素剪切出来，临时挂到
<body>下测试，验证是否真由上下文导致 - 避免对非必要容器设
will-change: transform，它比transform更容易隐式创建层叠上下文
position 用 relative 还是 absolute？
只要是为了控制层级，优先用 position: relative：它不改变文档流位置，又能让 z-index 生效，最安全。
用 position: absolute 时要注意：
- 必须确保其最近的已定位祖先能提供合理参照（比如
position: relative） - 若父容器设了
overflow: hidden、auto或scroll，会直接裁剪子元素，z-index根本没机会起作用 - 不要依赖 HTML 文档流顺序赌谁在上——后写的
static元素可能盖住前写的absolute元素，这是不可控的 fallback 行为
z-index 数值怎么设才不翻车
z-index 不是越大越好，而是要分组管理。全局乱堆 9999 或 2147483647 会导致后续组件（比如模态框、下拉菜单）无法插入中间层级，甚至压住别人正在动画的过渡层。
建议按功能划分区间：
--z-header: 100--z-dropdown: 200--z-modal: 1000--z-toast: 1100
z-index: auto 和 z-index: 0 效果不同：auto 不参与层叠排序，0 明确进入当前上下文的“默认层”；后者反而更容易意外触发新上下文。
负值合法，但需配合 overflow: visible 父容器，否则会被裁掉。
