从一次层叠上下文问题看CSS渲染顺序的本质

一次「z-index 明明很大却被盖住」的事故

事情起于一个看起来很普通的弹窗。页面里有个卡片列表，卡片为了动画性能，容器上挂了 transform: translateZ(0)，个别地方还配合了 will-change: transform。弹窗组件本身写得很标准：position: fixed; z-index: 9999。按直觉，它应该稳稳地盖在最上层，可实际效果是——弹窗被卡片遮住了一半，滚动时位置也怪怪的，像是「fixed 不 fixed」了。

打开 DevTools 一层层翻祖先节点，最后在卡片容器上发现了那个 transform。把它去掉，弹窗立刻恢复正常。于是问题来了：z-index: 9999 为什么干不过卡片？这背后其实是 CSS 渲染顺序里一个经常被误解的概念——层叠上下文（stacking context）。

层叠上下文不是 z-index 的附属品

很多人的心智模型是：z-index 是一个全局的「高度值」，谁大谁在上面。这个模型在简单页面里能跑通，一旦引入层叠上下文就崩了。真实规则是：z-index 只在同一个层叠上下文内部参与比较，跨上下文时它没有任何话语权。

可以把层叠上下文理解成一块「打包好的像素板」。当一个元素成为层叠上下文，它的所有后代——不管里面的 z-index 是 1 还是 99999——都会被压扁、打包成一个整体，然后这个整体只作为父级层叠上下文中的一个条目去参与排序。换句话说，子元素的 z-index 是「内部事务」，外界看不到。

在刚才的例子里，transform 让卡片容器成了层叠上下文，弹窗虽然 position: fixed，但只要它在 DOM 上仍处于这个容器内部，它就被关进了这块像素板里，9999 只能在板子内部称王。而板子整体在根上下文里的排序位置，是由它自己的层叠层决定的，跟弹窗的 z-index 毫无关系。

绘制顺序的本质：先分层，再比大小

浏览器绘制时并不按 DOM 顺序逐元素刷。在同一个层叠上下文内，大致按下面的顺序从下往上画：

1. 上下文根元素的背景和边框；
2. z-index 为负的子层叠上下文；
3. 块级非定位元素；
4. 浮动元素；
5. 行内元素与文本；
6. z-index: auto 或 0 的定位元素、层叠上下文；
7. z-index 为正的子层叠上下文。

注意这里的顺序：先按「层叠层」分类，再按树序，最后才比较 z-index。这就是为什么「调大 z-index」经常无效——你调的是同一个盒子里的数字，而盒子本身在上一层的位置早就定死了。

更本质一点说，渲染时存在两棵树：一棵是 DOM 树，一棵是层叠上下文树。后者才是绘制顺序的真正依据，它由前者的结构加上创建层叠上下文的属性共同决定。这棵树一旦成型，绘制就是一次先序遍历，每到一个上下文，先画自己的背景，再按层叠层把子项依次画上去。

那些「悄悄」创建层叠上下文的属性

除了 position 非 static 且 z-index 非 auto 这个经典组合，还有很多属性会顺手创建层叠上下文：

• position: fixed / sticky（现代规范下总是创建）；
• opacity 小于 1；
• transform、filter、perspective、clip-path、mask、backdrop-filter 非 none；
• will-change 指定了上述属性；
• isolation: isolate；
• mix-blend-mode 非 normal；
• contain: layout / paint / strict / content；
• flex / grid 子项且 z-index 非 auto。

这就是为什么问题往往出在「优化性能」的代码上：为了开 GPU 合成随手加的 transform 和 will-change，顺手就把整棵子树的层叠关系重排了。

排查与修复

遇到 z-index 失效，别急着加零，先按这个顺序查：

1. 从出问题的元素往上找，看最近的层叠上下文祖先是谁；
2. 判断它是不是被 transform、opacity、filter 之类意外创建出来的；
3. 如果必须保留这些属性，就把需要置顶的元素移出这个上下文——常见做法是用 Portal / Teleport 把它挂到 body 下，而不是靠 z-index 硬碰硬；
4. 或者主动用 isolation: isolate 把顺序控制「收敛」在一个局部，避免它外溢影响别人。

顺带一提，position: fixed 受祖先 transform 影响，还有一个独立的坑：transform 会改变 fixed 元素的包含块，让它相对该祖先而不是视口定位。这两件事经常同时出现，排查时要分开确认。

如果项目允许，更现代的方案是直接用 Top Layer：原生 <dialog> 的 showModal()、popover 属性，都会把元素提升到不受层叠上下文约束的顶层。这才是「真的在最上面」，而不是靠一个更大的数字去赌。

小结

z-index 不是全局高度，它只是层叠上下文内部的排序号。真正决定绘制顺序的，是每个上下文内部的层叠层规则，以及层叠上下文树本身的结构。理解了这一点，很多「玄学遮挡」都会变成可以推导的必然结果：先问这个元素属于哪个上下文，再问这个上下文排在哪里，答案自然就出来了。