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