层叠上下文是渲染域划分而非加速机制，触发后元素及其子树被隔离进独立z轴空间，z-index仅在内部生效；opacity<1、transform非none、filter有值等属性会悄悄创建上下文，导致层爆炸和掉帧。
层叠上下文不是“加了就变快”，而是“加了就多一层隔离”
浏览器构建渲染树时，一旦某个元素触发了层叠上下文（stacking context），它和它的整个子树就会被切进一个独立的 z 轴空间。这不是加速机制，而是一次「渲染域划分」——后续所有 z-index 比较、绘制顺序、合成层分配，都只在这个小圈子里发生。这意味着：父级的 z-index 再高，也管不到这个上下文内部；子元素再想“跳出来”盖住外面的兄弟，根本没通道。
哪些 CSS 属性会悄悄创建层叠上下文？
最容易踩坑的是那些“看似无害”的属性，它们在你没写 z-index 的情况下就已生效：
-
opacity值小于 1（哪怕opacity: 0.999） -
transform值不等于none（包括translateZ(0)、scale(1)、rotate(0deg)） -
filter有值（哪怕filter: blur(0)） -
will-change设为transform或opacity -
display: flex或grid的容器，只要子元素显式设置了z-index（哪怕只是z-index: 0）
这些属性本身不带层级语义，但浏览器必须为它们创建新的 PaintLayer，进而生成新渲染层 —— 这直接导致内存占用上升、图层合成路径变长、GPU 纹理上传次数增加。
层叠上下文过多会导致“层爆炸”，不是卡顿，而是掉帧
Chrome DevTools 的 Layers 面板里如果看到几十个浅色小方块（每个代表一个 Composite Layer），基本就是层爆炸了。这不是单纯“慢”，而是合成阶段频繁切换上下文、重复上传纹理、触发隐式重绘，最终表现为滚动或动画过程中帧率跌破 30fps，尤其在中低端 Android 设备上明显。
立即学习“前端免费学习笔记（深入）”；
典型诱因：
- 给每个卡片组件加
transform: translateZ(0)强制硬件加速 - 用
opacity实现淡入动画，却忘了动画一结束就恢复opacity: 1 - Grid 容器设了
opacity: 0.99，里面 20 个子项全被锁进同一层叠上下文，但又各自需要z-index排序
怎么验证某个元素是否意外进入了层叠上下文？
别猜，用 DevTools 实时看：
- 选中元素 → 右侧 Styles 面板 → 切到 Computed 标签页 → 搜索
stacking context，显示Yes即已创建 - 打开 Layers 面板（
More Tools → Layers）→ 点击任意图层 → 查看Stacking context字段是否指向该元素 - 观察 Elements 面板中该节点是否被渲染为独立图层（背景色变浅，且有图层编号）
真正麻烦的不是单个层叠上下文，而是嵌套创建：比如父容器因 opacity 创建了一层，子元素又因 transform 再建一层，子子元素再因 filter 建第三层……这种“层中层”会让合成路径指数级膨胀，而且无法通过简单删样式回退 —— 因为每一层都可能承载着不可见但必需的视觉逻辑。
