CSS层叠上下文：z-index 9999为何被压？一次讲透原理与排查

CSS的层叠上下文是我面试前端岗位时几乎必问的知识点，也是线上层级bug里最常被忽视的一个“隐形元凶”。如果你遇到过 z-index 设到 9999 仍然被压在下面的情况，大概率不是 z-index 不够大，而是层叠上下文的“作用域”把子元素的层级锁死了。这篇文章不打算从规范条文开始逐字背诵，而是从一个真实事故切入，把层叠上下文的定义、触发条件、浏览器渲染模型里的位置、以及实战中怎么快速定位和利用它，一次性讲透。

1. z-index 9999仍然被压住：从一次线上事故说起

1.1 事故现场：下拉菜单神秘消失

我之前维护过一个后台管理系统，里面有大量表格和弹窗。某天测试提了一个bug：表格某一行操作区里的“更多”按钮，点击后弹出的下拉菜单，在部分行上被相邻行的内容遮挡。更诡异的是，下拉菜单的 z-index 已经写到了 9999，相邻元素是一个普通到不能再普通的 div，z-index 根本就没设置过。

第一反应是“z-index 没生效”，于是我给下拉菜单加了 position: absolute，又确认了父元素没有 overflow: hidden，但问题依旧。后来仔细看了下拉菜单所在单元格的父级，发现问题不在菜单本身，而在整个表格容器的祖级元素上。那个祖级元素设置了 transform: translateX(-50%) 来做居中，而 transform 一旦生效，就会创建一个层叠上下文。下拉菜单哪怕是 z-index: 9999，也只是在这个“层叠环境”内部排老二，出了这个环境，它再大也翻不过外面的普通元素。

这个事故非常典型，从那次之后我就养成了习惯：遇到层级问题，先用元素面板把祖先链翻一遍，谁创建了层叠上下文，谁就是整个问题的边界。

1.2 为什么面试官喜欢问这个点

后来我参加前端岗位的面试，很多面试官都会问“层叠上下文的定义与触发条件”。起初我以为是考察背概念，后来才想明白，他们真正想了解的是：当线上出现层级遮挡时，你有没有一套清晰的定位逻辑。如果只记得“z-index 越大越靠上”，那遇到 transform、opacity、filter 导致的层级错乱，就会完全摸不着头脑。

层叠上下文不是独立于 z-index 的另一套体系，而是 z-index 能在多大范围内生效的“范围圈”。理解了它，才算真正理解了 CSS 渲染模型中，元素在 Z 轴方向上是怎么被安排的。

2. 层叠上下文到底是什么：一套藏在渲染引擎里的“独立王国”

2.1 一个容易理解的类比

可以把层叠上下文想象成一个独立小屋。屋里摆放了很多家具，每件家具都有一个“楼层号”代表它在屋里的高度。屋外也有家具，外边家具的高度由屋外自己的规则决定。关键是：屋内的家具不管多高，它永远只能在小屋范围内“冒头”；小屋本身的“楼层”才参与屋外比较。

对应到 CSS：每个形成层叠上下文的元素，就是一个小屋。屋内子元素的 z-index 高低，只能在屋内分高下；这个元素自身作为整体，和外部元素比较时，使用的是该元素自己（或者说这个层叠上下文根节点）的 z-index。所以就会出现“子子孙孙里有人 z-index 是 9999，却干不过外部一个 z-index: 1”的情况，因为比较发生在两个不同小屋之间时，屋子内部的家具高度不算数。

这个模型不一定精确到规范用词，但对理解层叠上下文非常有用。CSS 渲染引擎实际做的是：按元素在文档树中的顺序，加上层叠上下文这个约束条件，递归地对所有元素进行层叠排序。每个层叠上下文内部的排序是原子的——要么整体在外部排序中靠前，要么整体靠后，不会出现“内部某元素越过边界插到别处”的情况。

2.2 层叠水平与层叠顺序：层叠上下文内部的基本法

在同一个层叠上下文内部，所有子元素在 Z 轴方向上存在一个固定的绘制顺序，专业叫法是“层叠顺序”（stacking order）。这个顺序从低到高大致是:

1. 层叠上下文的背景和边框
2. 拥有负 z-index 的定位子元素（以及 z-index 为负的 flex/grid 子项）
3. 非定位的块级元素
4. 浮动元素
5. 非定位的行内元素
6. z-index: 0 或 z-index: auto 的定位元素（以及 z-index: 0 的 flex/grid 子项）
7. 正 z-index 的定位元素

很多人只记住 “z-index 越大越靠上”，但没注意到“背景和边框永远在最底层”，也没有理解“负 z-index 元素处于块级元素之下”。正因如此，遇到“负 z-index 想把元素塞到父级背景底下”这类需求时，动不动就失败，原因就在这里：如果父级自身形成了层叠上下文，那么父级背景和边框在第 1 层，负 z-index 子元素在第 2 层，子元素永远盖在父级背景上方——除非父级不创建层叠上下文，子元素才能“穿过”父级背景跑到更底下。

这里面还有一个容易混淆的概念：层叠上下文和 BFC（块级格式化上下文）不是一回事。BFC 解决的是内部元素对外的布局影响，比如边距合并、浮动环绕、清除浮动；层叠上下文解决的是 Z 轴排序影响。虽然某些触发条件相同（比如 overflow: hidden 会创建 BFC，但不创建层叠上下文），但两者的作用域规则完全不同，定位问题时不能混为一谈。

3. 触发条件全景图：从基础属性到隐蔽属性

3.1 传统定位与 z-index 触发

层叠上下文最基础的触发方式，是 CSS 定位元素（position 值不是 static）设置了有效的 z-index，且 z-index 不等于 auto。这里的 z-index 可以是正数、0，也可以是负数。换句话说:

• position: relative + z-index: 1
• position: absolute + z-index: 0
• position: fixed + z-index: 10

以上都会创建层叠上下文。单看这一条规则，很多前端开发者都能答出来，但易错点在于：position: relative + z-index: auto 不创建层叠上下文。也就是说，光设置了 position 还不够，z-index 必须是一个有效整数。

另一个容易漏掉的是 position: fixed。在主流现代浏览器中，position: fixed 元素即使不设置 z-index，也通常会形成层叠上下文，这主要是因为固定定位元素经常脱离文档流，渲染引擎需要把它作为独立层合成。尤其移动端项目里，fixed 元素导致的层级穿透问题，基本都跟这个点相关。

3.2 CSS3 属性触发的 6 个高频入口

CSS3 普及之后，触发层叠上下文的途径大幅增加，这也是“层叠上下文”这一个知识点从 CSS2.1 时代的小透明，变成面试高频考点的根本原因。现代 Web 布局里，就算完全不写 position，元素也可能因为下面这些属性形成层叠上下文：

• opacity 小于 1（哪怕 0.999 也触发）
• transform 不为 none（translate(0,0) 也算）
• filter 不为 none（blur(0)、brightness(1) 同样触发）
• backdrop-filter 不为 none
• clip-path 不为 none
• mask 或 mask-image 不为 none

这几个属性触发的层叠上下文，是很多“莫名其妙被遮挡”问题的真正推手。注意，这里的“不为 none”不是指视觉上必须有效果，而是指 CSS 计算后的属性值本身就不是默认值。很多人会将 transform: translate(0, 0) 或者 filter: blur(0) 当作“无效果、可忽略”，但实际上渲染引擎不这么认为——只要属性不为初始值，层叠上下文就会成立。

3.3 “隐身触发”的一类属性：will-change 与 contain

除了直接改变视觉的属性，还有一类属性是“为性能优化而生”，但它们也会悄悄创建层叠上下文。最典型的就是 will-change。只要 will-change 指定了 transform、opacity、filter 等属性，哪怕元素当前并没有任何实际变化，浏览器也会提前为元素创建合成层和层叠上下文。这个设计初衷是让动画更顺滑，副作用是如果你在大量列表项上统一写了 will-change: transform，内存和合成层数量都会明显上升，滚动性能不升反降。

contain 属性也是容易被忽略的重灾区。contain: layout、contain: paint、contain: strict、contain: content，只要命中，就等于告诉浏览器“这个元素的内部渲染与外部隔离”，所以浏览器会主动为其创建一个独立的层叠上下文。这正好解释了为什么某些组件库里的卡片、列表项在加了“性能优化”属性后，内部 z-index 突然变得不听话了。

3.4 触发条件完整对照表

为了方便查漏补缺，我把常见触发条件汇总成一张表：

看到这张表，你大概就理解了为什么线上层级 bug 那么难查：每一个属性都可能是“隐藏开关”。排查时不能只盯z-index，还要把祖先链上所有元素的计算样式翻一遍。

4. z-index: auto、z-index: 0 与负 z-index 的微妙差异

4.1 auto 和 0 之间隔着一层上下文

z-index: auto 与 z-index: 0 在视觉排序上处于同一层叠级别，但在“是否创建层叠上下文”这个问题上是完全不同的答案。z-index: 0 明确创建层叠上下文，z-index: auto 不创建。这个差异在项目中的后果非常明显。

举个例子：有两个兄弟元素 A 和 B，A 设置了 position: relative; z-index: auto，B 设置了 position: relative; z-index: 0。A 里面有一个子元素 A-child，z-index 为 9999；B 里面有一个子元素 B-child，z-index 为 1。因为 A 没有创建层叠上下文，A-child 实际上会“逃”出 A 的约束，直接参与页面的层级比较；而 B 创建了层叠上下文，B-child 被关在 B 内部。最终结果是 A-child 会盖在 B 之上——哪怕 B 自己已经形成了独立的层。这在某些弹窗场景里会造成“弹窗背景层明明想让内容层盖住，结果内容层跑别人家去了”的诡异现象。

所以，当你希望“孩子辈”元素能够在更大范围内参与层叠竞争，就不要随手给父级设置 z-index: 0；反过来，如果你希望某个容器内部自成一体、不受外部影响，z-index: 0 就是一种非常省事的“隔离手段”。

4.2 负 z-index：想藏到背景下面，没那么简单

负 z-index 的应用场景一般是把装饰元素放到内容层的下方，比如卡片底部的光影、色块。很多人会直接写：

css复制.card {
  position: relative;
}
.card::before {
  position: absolute;
  z-index: -1;
  background: #f0f0f0;
}

这套写法能不能生效，取决于 .card 是否创建了层叠上下文。如果 .card 只是 position: relative + z-index: auto，那么 ::before 的负 z-index 会跑到 .card 背景层下方，效果正常；但如果 .card 因为某些原因带上了 z-index: 0、transform、opacity 等属性，创建了层叠上下文，那么负 z-index 子元素只会盖在 .card 背景之上、内容之下，根本穿不到 .card 的背景下面去。

具体说，负 z-index 子元素在层叠顺序中处于第 2 层，而层叠上下文自身的背景和边框在第 1 层。所以只要父元素创建了层叠上下文，它的背景就被“锁死”在最底部，负 z-index 子元素无论如何都只能飘在背景上方。想要那种“伪 3D 浮出卡片”的光影效果，通常的解法是不要让父元素成为层叠上下文，或者用额外的包裹元素把背景层单独隔离出来。

4.3 定位元素与 flex/grid 子项的负值差异

在传统定位元素中，负 z-index 结合 position 使用；在 flex/grid 布局中，情况稍微不同。flex 或 grid 容器的直接子项，即使 position 是 static，只要 z-index 不等于 auto，也会创建层叠上下文，负 z-index 同样参与排序。

所以如果你用 flex 做卡片墙，想让某张卡片“沉”到其他卡片下方，可以这样写：

css复制.container {
  display: flex;
}
.card--bottom {
  z-index: -1;
}

这不需要给 .card--bottom 加 position，因为 flex 子项本身就支持 z-index 参与层叠排序。grid 子项同理。这在写复杂网格布局时非常实用，不用再为了调整层级而给所有元素加 position。

5. 现代 CSS 布局下的触发差异：flex、grid、transform 与动画

5.1 为什么现在层级 bug 比以前多

CSS2.1 年代，页面布局主要靠 float、position，能触发层叠上下文的属性很有限。现在 flex、grid 普及，transform、filter、opacity 满天飞，再加上动画库和组件库无处不在，任何一个属性都可能改变层叠上下文。结果就是：十年前一个 z-index: 9999 能解决绝大多数层级问题，现在 z-index 只是起点，不是终点。

我在项目中明显感受到，凡是用了 transform 做位移动画、scale 做 hover 缩放、filter 做模糊遮罩、opacity 做淡入淡出的地方，几乎都是层级 bug 高发区。原因不是属性本身有 bug，而是它们改变了层叠上下文的结构，导致原本设计好的 z-index 体系失效。开发的时候如果没意识到这一点，测试一拖动页面、一 hover 卡片，层级就乱套。

5.2 动画期间的临时层叠上下文

动画和过渡也有特殊性：如果动画或过渡过程中涉及 transform、opacity、filter 等属性，那么在动画运行期间，元素会临时创建层叠上下文；动画结束后，如果属性恢复为初始值，这个层叠上下文可能随之消失；如果使用了 animation-fill-mode: forwards，终态样式会一直保留，层叠上下文也会一直保留。

一个典型坑是这样的：一个弹窗从显示到隐藏的过渡动画，在显示过程中使用 transform: scale(0.8) → scale(1)，动画结束后 transform 停留在 scale(1)。因为 forwards 保留了终态，弹窗根节点就一直保有 transform 这一属性值，从而一直创建着层叠上下文。弹窗里的内容再想把遮罩层顶起来，或者外部组件想覆盖弹窗内容，都要受到这个层叠上下文的约束。解决方式通常是动画结束后手动移除 transform，或者在根节点上用 isolation: isolate + z-index: 999 来明确隔离边界。

5.3 transform 对 fixed 子元素的连带影响

还有一个连带效应必须提：transform 不为 none 时，不仅创建层叠上下文，还会成为内部 position: fixed 元素的包含块。所以一个 fixed 弹窗如果放在带 transform 的父级里，它的“固定定位”就失去了相对于视口的效果，变成了相对于父级定位。这个现象常被误认为“fixed 失效”，其实也是 transform 改变了定位参考系。

由于包含块和层叠上下文经常同时出现，定位 bug 和层级 bug 往往会同时在页面上爆发。排查顺序也可以反过来：先看祖先链是否带 transform，如果带了，fixed 子元素的行为会先出问题，层叠顺序再跟着乱。这条经验在调试移动端项目时尤其有效，因为移动端 transform 使用频率极高。

6. 层级错乱实战排查链路：浏览器工具与二分定位法

6.1 排查三步走：先看链、再看值、最后删除验证

遇到层级问题，我有一套固定的三步排查流程。第一步：找到目标元素，自下而上把祖先链上所有元素的计算样式过一遍，重点看有没有 transform、opacity、filter、will-change、contain、isolation 这些“隐藏开关”。第二步：检查目标元素自身的 position 和 z-index，确认它是不是参与层叠比较的那个元素，说不定问题元素根本不是你最先看到的那个。第三步：临时删掉或注释掉某个可疑属性，看层级是否立刻恢复，用删除验证法锁定元凶。

比如前面说的下拉菜单案，我就是在元素面板里一层一层向上翻，翻到表格容器祖级时看到 transform: translateX(-50%)，然后临时去掉这个 transform，下拉菜单瞬间就正常了。整个过程不超过两分钟。这也说明了为什么排查层级问题不能用“肉眼猜测”，必须沿着祖先链去翻计算样式。

6.2 DevTools 的层叠上下文可视化能力

现在浏览器 DevTools 已经提供了不少辅助能力。Chrome DevTools 的 Elements 面板中，选中某个元素后，在“Styles”面板下方可以查看层叠上下文相关的提示；在 Rendering 面板里可以开启“层叠边界”（Stacking borders）和“层叠顺序”（Stacking order）的调试遮罩。前者会在页面上用高亮线画出所有创建层叠上下文的元素边界，后者则会显示当前视口内元素的层叠顺序编号。

这个可视化工具在排查复杂层级问题时非常管用。我平时会开启“层叠边界”，先把页面上到底有多少个层叠上下文看个明白，往往一眼就能发现“为什么这里有个不该出现的 transform 元素”。不过要注意，开启层叠顺序遮罩后页面上的数字是动态变化的，在某些 hover 或动画状态下，数字会频繁跳变，不影响定位，但别被数字大小误导。

6.3 二分定位法：快速缩小层叠上下文范围

如果层级问题涉及的元素嵌套很深，一个一个排查效率太低。我的做法是二分定位：先找到“问题元素”和“被遮挡元素”的最近公共祖先，然后从公共祖先开始，看一下它内部到底有几层容器创建了层叠上下文，再在这些真正创建了层叠上下文的节点中间做二分测试。

比如公共祖先下面的层级大概是：A 容器（transform）→ B 容器（opacity: 0.99）→ C 容器（无特殊属性）→ 问题元素。那么问题大概率出在 A 或 B 上。把 A 的 transform 临时去掉，层级恢复正常，说明边界就是 A；如果没有恢复，再把 B 的 opacity 临时改为 1，以此类推。用这种办法，即使嵌套 20 层，也能在几次试验内锁定具体节点。

还有一个经验：不要只盯着“会变化的属性”，像 will-change、contain 这类看起来人畜无害、甚至不产生视觉效果的属性，恰恰是最容易让排查绕远路的。因为它们平时根本不会被注意到，只有删掉之后才能感受到变化。

7. 用层叠上下文做“隔离”：三个能直接抄的工程方案

7.1 弹窗与第三方组件库的 z-index 冲突

后台管理系统最大的层级痛点，就是有自己的弹窗、第三方组件库的弹窗、还有各种 tooltip、popover 混在一起。各家组件库内部对 z-index 的管理方式不同，有的默认 1000，有的默认 9999，互相覆盖的情况时有发生。

层叠上下文提供了一个非常优雅的解决方案：给每个弹窗的挂载节点设置 isolation: isolate，或者给整个应用设置一个主层叠上下文，然后让所有弹窗在 z-index 上用一个统一的区间。比如：

css复制.app-root {
  isolation: isolate;
  position: relative;
  z-index: 0;
}
.modal-wrapper {
  position: fixed;
  z-index: 1000;
}

这样外部再怎么出现奇怪的 transform 或 filter，也不会干扰应用内部的弹窗层级，因为 .app-root 作为层叠上下文已经把所有内部元素“包”起来了。项目里如果多个弹窗并存，再给每个弹窗单独的 z-index 区间，就能做到全局层级可控。

7.2 swiper/carousel 里下拉菜单被相邻卡片遮挡

轮播图（swiper/carousel）场景也是一个高频事故区。轮播容器为了实现切换动画，几乎都会用到 transform: translateX，于是整个轮播轨道就形成了一个层叠上下文。结果就是：第一张卡片里的下拉菜单即使 z-index 很大，也会被第二张卡片的内部元素遮挡，因为它们的层级比较发生在轨道内部，而不是页面级别。

工程上的解法有两种：一种是把下拉菜单改成用 teleport/portal 挂载到 body 下，让菜单脱离轮播轨道这个层叠上下文；另一种是给轮播容器设置 isolation: isolate + 一个较合理的 z-index，保证整个轮播在页面上形成一个稳定层级，但这只能解决轮播与外部元素的比较，不能解决轮播内部子元素之间的遮挡。

如果不想把菜单挂到 body，还可以在轮播卡片之间做“兄弟层级”管理：让当前激活的卡片 z-index 提高，其他卡片全部放在同一层级之下，同时确保卡片自身不触发层叠上下文。这需要组件逻辑配合，但效果最可控。

7.3 hover 缩放卡片时的心机层级提升

现在很多展示型网站喜欢做卡片 hover 放大效果，写法一般是 transform: scale(1.05) + transition。这个 transform 一出现，卡片就成了层叠上下文。问题是，当多张卡片都在同一层叠上下文内部时，hover 放大的卡片会盖住相邻卡片吗？答案是有条件：会，但只会在同一层叠上下文内部生效。

由于每张卡片都是兄弟元素，同属一个父级层叠上下文，所以后绘制的兄弟会盖住先绘制的兄弟。如果想让 hover 的卡片即使位于文档流前面，也能够在缩放时盖住后面的卡片，需要给 hover 状态提升 z-index：

css复制.card:hover {
  transform: scale(1.05);
  position: relative;
  z-index: 1;
}

不过要小心一个细节：如果父级是 flex 布局，卡片本身已经是 flex 子项了，即使 position 不设置，z-index 也能生效；但如果父级是普通 block 布局，就必须额外给 position: relative。这个差异经常导致“同类代码在 flex 布局里有效，换成 block 布局又失效了”的现象。

我在实际项目里还习惯给 hover 缩放卡片的父级设置一个 isolation: isolate，把整个卡片组隔离成独立层叠上下文，这样卡片组的整体层级不会跟页面其他组件冲突，内部的 hover 提升只影响组内排序，互不干扰。这个方案用下来非常稳，推荐大家直接参照。

从最开始那个“z-index 9999 还是被压住”的事故，到后来在项目中熟练地用 isolation 隔离弹窗、处理轮播下拉菜单、修复卡片 hover，我对层叠上下文最大的体会是：它不是一道需要死记硬背的面试题，而是一套解释“元素在 Z 轴怎么排”的底层模型。真正理解了触发条件和作用域边界之后，再复杂的层级问题也只是几步定位的事。以后遇到类似 bug，别急着给 9999 加个进位，先问问自己：这个元素，到底活在谁的小屋里。