为什么css中设置z-index为999依然被其他元素遮挡_排查同级元素的堆叠顺序-css教程-PHP中文网

z-index 999被盖住的根本原因是元素未定位或受父级层叠上下文限制：z-index仅对position为relative/absolute/fixed/sticky的元素生效，且只在同一个层叠上下文中有效；父元素若含opacity

为什么css中设置z-index为999依然被其他元素遮挡_排查同级元素的堆叠顺序

z-index 999 为什么还是被盖住？先看它有没有生效

z-index 只对 position 值为 relative、absolute、fixed 或 sticky 的元素起作用。如果目标元素仍是 static（默认值），哪怕写 z-index: 99999，浏览器也直接忽略。

检查方式：在 DevTools 中选中该元素，看 Computed 面板里 z-index 是否显示为 999；若显示 auto，说明 position 没设对，或被其他 CSS 覆盖重置了。

常见漏点：position: static 被父级 transform 或 opacity: 0.99 暗中触发新层叠上下文，导致子元素的 z-index 失效范围缩小
别只改子元素——先确认父容器有没有意外创建层叠上下文（比如加了 transform: translateZ(0)）
用 DevTools 的“Layers”面板（Chrome）或“3D View”（Firefox）直观观察层叠结构

同级元素堆叠顺序不按 z-index？查它们是否在同一个层叠上下文里

两个元素即使 DOM 位置相邻、z-index 差 1000，只要分属不同层叠上下文，就无法直接比较。比如 .modal 在 #app 内，而遮挡它的 .header 是 body 直接子元素——它们的共同祖先可能是 body，但各自父级已分别创建了独立层叠上下文。

哪些属性会强制创建新层叠上下文？

position: relative/absolute/fixed + z-index 值不为 auto
opacity 小于 1（哪怕 0.999）
transform 不为 none（包括 translateZ(0)、scale(1)）
will-change: transform、filter、mask 等

关键判断：打开 DevTools → Elements → 右键目标元素 → “Show stacking context”。如果某父级被标为 “stacking context”，那它内部的所有 z-index 都只能在这个小世界里排序。

CSS工具箱(专业版)

全功能 CSS 工程手册，覆盖性能优化、无障碍、设计系统与跨浏览器兼容。

下载

被遮挡的元素明明 position 正确，z-index 也生效，但还是压不住？看父级 z-index 是否拖后腿

子元素的 z-index 再高，也无法突破其所在层叠上下文容器的层级。例如：

<div class="header" style="position: relative; z-index: 10;">
  <div class="dropdown" style="position: absolute; z-index: 999;"></div>
</div>
<div class="content" style="position: relative; z-index: 20;"></div>

这里 .dropdown 的 z-index: 999 完全无效——它被死死锁在 .header（z-index: 10）这个容器里，而 .content 的 z-index: 20 更高，所以整个 .header（含下拉菜单）都被压在下面。

解决方向不是给子元素加更大 z-index，而是提升其**最近的层叠上下文容器**的 z-index
如果容器本身不能动（如第三方组件封装的 header），可尝试在它外层包一层 div 并设 position: relative; z-index: 100
警惕 overflow: hidden 父级——它虽不创建层叠上下文，但会裁剪子元素超出部分，造成“被遮挡”假象

ECharts / Ant Design / Vue 组件弹层被盖？优先检查框架默认样式是否悄悄建了层叠上下文

很多 UI 库或图表库会在根容器上加 transform 或 opacity 用于动画或过渡效果，这会无意中让整个组件树陷入一个低层级的层叠上下文。比如 ECharts 的 tooltip 默认是 position: absolute，但如果它挂载在某个带 transform: scale(1) 的 div 下，再高的 z-index 也出不去。