下午五点多，某后台系统的测试同学甩来一张截图：新增弹窗又被列表表头遮住了，弹窗上那个z-index: 99999明晃晃写着，却像个摆设。我第一反应不是去加更大的数值，而是打开DevTools开始翻它的祖先链——因为这类“z-index设置了却没用”的遮挡问题，十有八九不是数值不够大，而是CSS层叠体系里更底层的规则在起作用：层叠上下文。如果你也在层叠一堆z-index却始终压不住元素，这篇内容应该能帮你少走几个小时的弯路。我会从z-index的生效前提讲起，剖析层叠上下文这个核心概念，再用几个真实场景复盘、一套可直接抄的排查脚本和工程化预防方案，把z-index无效的坑一次填平。

1. 先搞清z-index的生效条件：这两个经典误区最害人

很多人调试z-index时的第一反应就是“再调大一点”，从99加到999再加到99999，界面纹丝不动，于是开始怀疑浏览器坏了。实际上z-index并不是一个“谁数值大谁就赢”的无脑规则，它有一套严格的适用条件。绝大多数“失效”问题，根源都出在这套条件上。

1.1 不是所有元素都吃z-index：定位是前提

z-index属性只对定位元素（position为relative、absolute、fixed或sticky）以及部分特殊场景下的元素生效。如果一个元素保持着默认的position: static，你给它写z-index: 9999，浏览器会完全无视它，因为它根本不在z-index的适用范围内。

这个误区在教学里提过无数遍，但实际代码里几乎每天都能撞见。我记得有个项目里，同事给页脚的返回顶部按钮设置了z-index: 9999，结果按钮死活被侧边栏遮住，排查半天发现按钮的position被设成了static。我当时的建议很简单：把按钮设为position: fixed或者position: relative，再配合z-index，问题立刻消失。

为什么不加position就不行？可以把层叠顺序理解成排队：普通流里的元素是按文档顺序依次站队的，不需要额外编号；而z-index是给“能够插队/离队的元素”准备的编号牌。static元素老老实实在队伍里，不参与编号。

这里有一个容易忽略的补充：display: flex或display: grid的容器，其子项目即使保持position: static，设置z-index也同样生效。这是CSS3对flex/grid布局的额外规则。所以如果你在flex布局里遇到z-index“看起来有效”的情况，不奇怪——它走的是另一条适用路径。

1.2 z-index比较有“阶级”：同层叠上下文才能互相比较

就算你给元素加了定位、也写了z-index，它依然可能“失效”。原因在于：z-index的数值只在同一个层叠上下文内部做比较，不是一个页面上所有元素拿着z-index比大小。

这里需要介绍今天的主角——层叠上下文。你可以把它理解成一个封闭的“门派”：门派内部，弟子们按辈分排列；但对外的时候，整个门派只以“掌门”的身份参与比较。也就是说，一个元素就算z-index是几百万，只要它的父级没排在前面，它就只能乖乖跟着父级走。

举个最常见例子：组件A内部的弹窗设置z-index: 99999，组件B只是普通定位元素设置了z-index: 1，如果组件A的某个祖先创建了层叠上下文且自身级别低于组件B，那么弹窗再大也压不过组件B。因为在外层看来，比较的不是弹窗和组件B，而是“组件A这个整体”和“组件B”。

还有两个容易踩的细节：

• z-index: auto和z-index: 0不一样。定位元素设置z-index: 0会创建层叠上下文，而auto不会。很多基础组件里随手写的z-index: 0，可能正是把子元素关进盒子的元凶。
• 两个元素z-index相同并且处于同一上下文时，DOM中后面的元素覆盖前面的元素。这个规则在很多“改了半天不知道谁盖谁”的场景里特别有用。

2. 层叠上下文就是“关人的盒子”：它是遮挡问题真正的幕后黑手

排查z-index问题，核心不是盯着z-index本身，而是搞清楚哪些元素创建了层叠上下文，目标元素被关在了哪个“盒子”里。

2.1 什么属性会在HTML里悄悄生成盒子

不需要主动写z-index，下面这些属性只要出现，也会让元素自动创建层叠上下文。我把常用触发条件整理成了一张表，用的时候可以对照排查：

特别需要注意的是opacity和transform这两个“低调”的触发者。它们看起来和层叠毫无关系，但一旦出现，元素就从“普通流中的一份子”变成了“一个带围墙的盒子”。最常见的场景是动画：一个元素在动画过程中opacity降到0.5，动画结束后如果没把opacity恢复成1，它就会一直保持层叠上下文状态，把内部的浮层全都关住。

2.2 一个盒子内外两套规则：父子关系里的z-index陷阱

这是z-index失效最隐蔽的来源。

我先说结论：子元素的z-index只能决定它在父级上下文内部的位置，不能决定父级上下文在不同父级之间的位置。换句话说，只要父级是一个层叠上下文，它内部再怎么堆z-index，对外都只有一个“整体等级”。

举个例子你就明白了。假设页面结构是：

• 容器A，position: relative; z-index: 1，内部有一个子元素，z-index: 999；
• 容器B，position: relative; z-index: 100，内部有一个子元素，z-index: -1。

在父级比较时，谁在上？答案是容器B整体在上，因为比较的是A和B的z-index（1 < 100），完全不看容器内部子元素是多少。所以A内部的z-index: 999，在B内部的z-index: -1面前占不到任何便宜，因为B这个“盒子”本身级别高。

反过来，如果一个容器position: relative; z-index: auto，它不会创建层叠上下文，内部的定位元素就直接参与更上层级的比较。这也是为什么很多修复手段最终都要回到“少包一层盒子”或者“让盒子的级别提上去”。

2.3 负z-index不能无限垫底：背景色的层级关系

还有一个特别常见的误操作：用z-index: -1给元素做背景层，结果发现它根本垫不到底部，反而盖住了正文。

原因藏在层叠顺序表中。CSS层叠顺序（从底层到顶层）大致是：

1. 元素自身的背景和边框
2. 负z-index的层叠上下文
3. 普通流中的块级元素
4. 浮动元素
5. 普通流中的内联元素
6. z-index为auto或0的定位元素
7. 正z-index的层叠上下文

注意第1层：元素自身的背景和边框永远在最底层。也就是说，你想把一个元素用z-index: -1垫到某个父级背景之下，这个操作是不成立的——父级背景画在第1层，子元素即使z-index为负，也要画在第2层或更高，它的绘制顺序始终在父级背景之上。同理，想用负z-index让一个块盖过前一个兄弟元素的背景，也做不到，因为后者的背景在第1层，优先级天然高于任何z-index值。

所以负z-index适合用来“让元素退到普通内容下方”，但绝对不适合“退到背景下方”。如果这个需求真的出现，通常要换实现思路，比如用伪元素加isolation: isolate来构造隔离层。

3. 真实场景复盘：四个让我排查到崩溃的遮挡案例

光讲理论不够，我把几个有代表性的排查过程写出来。这些案例的共同点是：表面上看都是z-index不够大，实际上每个遮挡问题的根子都不一样。

3.1 案例A：弹窗盖不住全局遮罩，原来是被父级“拖累”了

现象：一个后台系统的弹窗组件，弹窗本身z-index: 9999，遮罩层z-index: 1000。结果弹窗打开后，遮罩是显示了，但弹窗永远在遮罩下面。

第一反应是弹窗z-index比遮罩大，为什么还是被压住？我打开DevTools看了两个元素的祖先链，发现问题出在DOM结构：

• 遮罩挂在body下，body下还有一堆页面内容；
• 弹窗不是挂在body下，而是挂在页面主内容容器main内部；
• main设置了position: relative; z-index: 1，刚好让main成为一个层叠上下文。

于是层级比较变成了这样：遮罩（z-index: 1000）在body这个根上下文里，和整个main（z-index: 1）比较；1000大于1，遮罩盖住了main。而弹窗虽然z-index是9999，但它被关在main内部，只能跟main内部其他元素比大小，对外它的上限就是main这个盒子的等级。

修复方法：把弹窗组件从main里挪出去，直接挂载到body，和遮罩放在同一个根层叠上下文里。这样弹窗9999自然大于遮罩1000。如果不方便改DOM结构，也可以在main上把z-index提到遮罩之上，但这通常会影响整体布局，所以把浮层移出主容器才是更稳妥的方案。现在很多前端框架提供“挂载到指定节点”的能力，思路基本就是解决这类问题。

3.2 案例B：hover下拉菜单被相邻区块盖住，transform残留惹的祸

现象：侧边导航的hover下拉菜单设了z-index: 9999，但鼠标划过时，菜单被右侧内容区域的卡片盖住半边。

排查时我先确认了菜单本身定位没问题、z-index也没有写错，然后打印它的祖先链，发现了有嫌疑的祖先：导航容器上残留着一行transform: translateZ(0)。

这行样式很典型。早期做GPU加速优化时，很多人会给滚动容器或固定容器加transform: translateZ(0)或translate3d(0,0,0)来强制开启合成层，写完就再没管过。这个transform会让导航容器创建一个层叠上下文。于是下拉菜单的z-index只能在导航容器内部“横着走”，对外的时候，比较的双方变成了“导航容器”和“内容区”。内容区里恰好有卡片设置了position: relative; z-index: 1，而导航容器的z-index恰好是auto（或0），于是内容区整体排在导航之上，导航内部再大的z-index也出不了头。

修复时有两条路：

• 去掉导航容器上残留的transform，让下拉菜单回归到根层叠上下文，直接和内容区比较层级；
• 保留transform（毕竟GPU加速在某些场景有效果），但给导航容器显式设置一个比内容区更高的z-index，比如z-index: 2，让整个导航容器从外部层级上先赢过内容区。

我最后选了第二条，因为导航容器上有不少fixed定位需求，保留transform性能收益更稳定。下拉菜单内部其实只需要一个很小的z-index，比如z-index: 1，就能盖住容器内的其他元素。

3.3 案例C：吸顶导航盖不住内容，忘了加z-index

现象：页面的position: sticky吸顶导航，明明top: 0已经生效了，但滚动时，标题下面的卡片会从导航上边穿过去。

这个案例初看很奇怪——sticky元素确实是定位元素，应该天然在普通流内容之上。但仔细看规则：position: sticky确实是position非static，但它只有设置了z-index后才会在层叠顺序里占据高位；如果z-index还是auto，它属于第6档（z-index为auto或0的定位元素）。而页面里一些内容卡片设置了position: relative; z-index: 1，属于第7档，比sticky导航高了整整一档。

所以在滚动过程中，卡片从下方“钻”上去，导航却没能力把它盖住，视觉上就成了内容穿过导航。这个问题的修复极其简单：给吸顶导航加一个适中的z-index，比如z-index: 100，它就能压制页面上绝大多数内容元素。

这个案例教会我一件小事：sticky和fixed只是“定位方式”，不代表“层级优势”。定位解决的是位置问题，z-index解决的才是层级问题，两者经常需要一起使用。

3.4 案例D：卡片阴影的filter，把整个卡片的浮层“封印”了

现象：商品卡片列表里，鼠标悬停在某张卡片上时，卡片右上角的角标浮层会被后面一张卡片的轮播图盖住。角标z-index是99，轮播图组件内部z-index是500，前者的数值明明小，按理说盖不住也正常。但问题是，如果我把轮播图的z-index调小，角标还是被整张后面的卡片盖住。

这次打印祖先链后，发现一个“意外”的层叠上下文触发者：卡片外层使用了filter: drop-shadow(...)来给卡片整体加投影。filter会创建层叠上下文，也就是说每张卡片都是一个独立的“盒子”。卡片之间比较层级时，只看卡片本身的顺序和z-index，完全不看里面的角标和轮播图。由于它们同为普通元素且层级相同，后面的卡片整体压在前面卡片之上，所以前一张卡片的角标浮层怎么也跳不出来。

修复方案有两个方向：

• 如果阴影效果换用box-shadow就能满足，直接替换，因为box-shadow不会创建层叠上下文，问题立刻消失；
• 如果投影需要贴合不规则形状，只能用drop-shadow，那就把角标浮层通过挂载节点移到卡片容器之外，让它在根层叠上下文里参与比较。

从这个案例之后，我对filter、transform这类“会筑墙”的样式变得格外敏感。给一个容器添加这类视觉效果之前，先想想它内部是否存在浮层、弹层类元素，否则一旦被关住，调整起来的成本远高于一开始的视觉收益。

4. 一套能落地的排查流程：从Console脚本到二分定位

理论知识再多，遇到实际问题还是需要一个标准化的排查流程。我总结了一套自己的方法，每次遇到z-index遮挡都是这么查的，屡试不爽。

4.1 用脚本打印目标元素的所有祖先上下文信息

在DevTools中，$0代表你在Elements面板里当前选中的元素。在Console里运行下面这段函数，它会从目标元素一路向上，打印每一级祖先的关键样式，并标记出“大概率创建了层叠上下文”的节点：

function checkStackingContexts(el) { let node = el; const list = []; while (node && node.nodeType === 1) { const s = getComputedStyle(node); const data = { tag: node.tagName.toLowerCase(), className: String(node.className), position: s.position, zIndex: s.zIndex, opacity: s.opacity, transform: s.transform, filter: s.filter, willChange: s.willChange, isolation: s.isolation, mixBlendMode: s.mixBlendMode, backdropFilter: s.backdropFilter }; const signs = [ data.position === 'fixed', data.zIndex !== 'auto', parseFloat(data.opacity) < 1, data.transform !== 'none', data.filter !== 'none', data.isolation === 'isolate', data.mixBlendMode !== 'normal', data.backdropFilter !== 'none' ]; data.likelyBox = signs.some(Boolean); list.push(data); node = node.parentElement; } console.table(list); } checkStackingContexts(document.querySelector('你的目标元素选择器'));

用法很简单：

1. 在Elements面板中选中那个“被遮挡的目标元素”；
2. 切到Console，执行checkStackingContexts($0)；
3. 查看likelyBox为true的祖先，它们就是潜在的层叠上下文“盒子”。

这个脚本能帮你快速回答一个核心问题：目标元素到底被关在了哪个盒子里。尤其适合分析那类“数值写了却完全无效”的情况。

4.2 手动二分法：每次剥掉一个可疑属性，看现象是否变化

脚本只能帮你找出候选，真正定位根因，还需要验证。我的做法是“二分法”。

如果你怀疑某个祖先的transform在捣鬼，就直接在Console里临时改掉它：

document.querySelector('祖先选择器').style.transform = 'none';

改完立刻看页面遮挡有没有恢复。如果恢复了，说明这个祖先就是根因；如果没变，把它改回去，继续试验下一个可疑属性，比如：

document.querySelector('祖先选择器').style.opacity = '1'; document.querySelector('祖先选择器').style.filter = 'none'; document.querySelector('祖先选择器').style.isolation = 'auto';

这个方法不需要读太多规范，也不需要记触发条件的完整列表，只要按照嫌疑程度逐个剥离，通常几分钟就能锁定问题节点。唯一需要注意的是，每次只改一个属性，改完记住原值，方便还原。

4.3 一个普适的“三步判断法”

前面的脚本和二分法解决的是“哪里出了问题”，这里再给一个纯逻辑层面的判断法，适合在现场直接脑补推导。

第一步，先确认目标元素是否有使用z-index的资格：它是定位元素，或是flex/grid子项。如果没有资格，问题不在层级，而在定位方式上。

第二步，找到目标元素和被遮挡它的元素之间的共同祖先，看这个共同祖先是否创建了层叠上下文。如果共同祖先是普通static元素，说明双方在同一上下文里，直接比z-index和DOM顺序就行；如果共同祖先本身有transform、opacity之类的属性，说明双方被隔离在不同的“盒子”里，单凭数值是比不出来的。

第三步，判断“赢家”欠缺的到底是什么：是数值不够，还是父级盒子整体输给了对方。如果是后者，即使把数值拉到无限大也没用，要么提升父级盒子参与外部比较时的级别，要么把目标元素移到更合适的上层容器。

为了偷懒，我还做了一张检查清单，平时排查基础遮挡问题时直接照着过一遍。

5. 修复方案与工程化预防：别让z-index问题反复杀死你的周末

排查出根因只是第一步，真正重要的是形成“以后不再犯”的套路。下面这套方案我用了好几年，基本能避免九成以上的层级问题。

5.1 修复优先级：改结构 > 加层级 > 调上下文

遇到任何层叠问题，我建议先按这个优先级考虑方案，而不是一上来就改z-index。

首选的思路是改结构：让需要比较层级的元素处于同一个上下文里。最简单的方法是不要把弹窗、浮层写进那些可能被关住的内容容器里，而是统一挂到body或某个全局浮层容器下。这样它们天生在根级上下文里，z-index之间的比较非常直观。

其次是加层级：如果结构一时改不动，退一步考虑在当前上下文内调整z-index。注意是“调整”，不是无脑增大。同一上下文里只要数值比对方大且有定位，就能赢。如果整个父级盒子输给了另一个盒子，这时候增加层级也无效，需要回到改结构。

最后才考虑调整上下文：比如给某个容器加isolation: isolate来主动隔离，或者通过删除残留的transform/opacity让元素回归普通流。这类操作对全局影响较大，用之前要仔细评估。

5.2 Portal/Teleport：让全局浮层脱离盒子

前面几个案例的通用解法，本质上都是在“把浮层移出盒子”。这也是现在的组件库处理弹窗时的常见思路：提供一个挂载点，把内容渲染到body下或者另一个指定的顶层容器里。

如果你的项目里没有框架提供的这类机制，也可以手动做。在原生JavaScript里，动态创建浮层时直接把节点append到document.body上；在CSS层面，给body下准备一个所有浮层共用的div，让弹窗、下拉、提示全都挂进去。这样层级关系就简化成了“都是body的孩子”，谁数值大谁在上，清晰好排查。

需要注意的是，挂载出去之后要自行处理样式隔离和事件冒泡问题。比如弹窗的样式如果依赖父级容器类名，挂到body之后可能丢失继承，这时需要把公共样式抽成全局面板类，保证渲染层级和样式定义分离。

5.3 建立z-index分层规范与团队约定

团队开发里最怕的是各写各的数值——有人用10，有人用10000，还有人用六年没删的99999。一旦出现冲突，根本分不清优先级。我自己习惯用CSS变量定义一套层级体系，给不同用途的元素分配统一的档位：

:root { --z-back: -1; --z-base: 0; --z-sticky: 100; --z-dropdown: 1000; --z-overlay: 2000; --z-dialog: 3000; --z-toast: 4000; }

使用时不要直接写死数字，而是引用变量：

.header { z-index: var(--z-sticky); } .dialog { z-index: var(--z-dialog); }

这样看代码的人一眼就能明白某个元素大概处于什么级别，而不是面对一坨看不懂的数字发愁。每档之间留足了空间，以后即使在中间插入新层级（比如气泡、步骤条提示），也不用把所有旧数字推翻重来。

搭配几条团队约定会更有效：

• 默认不写z-index: 0，除非明确需要创建层叠上下文；
• 禁止为了“压过一切”随手写99999，先确认层级档位；
• 浮层类组件统一走Portal/挂载容器，不在业务内容容器里靠z-index硬顶；
• 动画结束时清理opacity和transform的残留值，尤其是GPU加速优化留下的行内样式。

5.4 关于特殊属性使用的自觉：transform/filter/opacity不再只是“视觉效果”

最后想补一个观念上的提醒：在这三个属性上栽过跟头之后，我会在写任何视觉优化代码之前多问一句——这个属性会不会创建层叠上下文？会不会把关住我内部的浮层？

多少个半夜调bug到崩溃的案例，最后都指向一行看似无害的代码。比如为了让卡片阴影更柔和用filter: drop-shadow，为了让弹窗开合更顺滑加transform: translateY(0)，为了让图片懒加载加载时优雅淡入留下opacity: 0.9。这些属性不是不能用，而是用的时候要有意识地评估它的“副作用”。

几个我后来固定的习惯：

• 动画结束确保opacity回到1，transform等属性如果不再需要就清掉；
• 卡片阴影优先考虑box-shadow，不为了视觉效果牺牲层叠上下文的可控性；
• 主动隔离用isolation: isolate，把隔离作为一种显式的设计决策，而不是等到bug出现后再猜测；
• 给某个容器加filter或transform之前，先检查它有没有子元素具备浮层需求。

如今我调试层叠问题时，基本不看z-index的绝对值是多少，上来先找“谁被关在哪个盒子里”。数值只是同一组元素内部的排序号，脱离了上下文，它什么都决定不了。把这一点想透之后，再复杂的遮挡问题，也只是一次“找到盒子、打开盒子、重新排序”的过程而已。