z-index 本身不创建合成层，但会因触发层叠上下文（如配合 transform、opacity 等）间接导致合成层爆炸，引发性能问题；应解耦层级与合成控制，移除非必要提升属性，用 contain 或统一锚点优化。
z-index 本身不直接创建合成层，但它会间接触发合成层爆炸——关键在于它如何与层叠上下文（stacking context）交互。当多个 z-index 层级被错误嵌套或意外创建新层叠上下文时，浏览器可能为本不该独立合成的元素强制分配 GPU 图层，导致图层数量激增、显存占用飙升、滚动卡顿甚至崩溃。
识别 z-index 引发的隐式合成层
z-index 生效的前提是元素已建立层叠上下文。而创建层叠上下文的属性（如 transform、opacity 、filter、will-change、isolation: isolate）往往同时触发合成层。问题常出现在“为了调层级而硬加 transform”的场景：
- 给弹窗父容器设
z-index: 1000，又为兼容性补上transform: translateZ(0)→ 父容器成合成层；其内部所有子元素若也带 z-index，可能因父级层叠上下文隔离而被迫各自升层 - 下拉菜单项用
opacity: 0.99实现淡入 → 每一项都创建独立合成层，而非复用父容器图层 - 轮播图容器设
will-change: transform，内部每张图又设z-index→ 浏览器无法合并图层，产生 N 个图层
用 Rendering 面板定位异常层叠结构
打开 DevTools → ⋯ → More Tools → Rendering → 勾选 Layer borders 和 Paint flashing：
- 绿色边框出现的位置，就是实际生成合成层的地方。若一个纯文本卡片（无动画、无透明）也有绿框，说明它被某个祖先的 z-index + transform 组合“连带升层”了
- 悬停在疑似错乱元素上，看 Styles 面板右侧是否显示 “Stacking context created by” —— 这行文字会明确指出是哪个 CSS 属性（比如
transform或opacity）创建了该层叠上下文 - 对比正常状态与悬停/展开后的 Layer borders 数量变化：若菜单展开后绿框数量从 1 跳到 50，说明 z-index 分布导致浏览器放弃图层复用
检查 Layers 面板确认图层归属与冗余
进入 DevTools → ⋯ → More Tools → Layers（或 Cmd/Ctrl+Shift+P 输入 “Show Layers”）：
- 按 Filter 输入
z-index或stack，快速筛选出与层叠逻辑强相关的图层 - 点击某图层，左侧高亮对应 DOM 节点；观察其 computed 样式中是否同时存在：
z-index: X+transform: ...+opacity: 0.999—— 多重触发条件叠加是典型冗余信号 - 注意图层尺寸：若一个
200×30px的按钮图层显示内存占用为~1.2MB，说明它未与父容器合并，而是被单独光栅化（常见于父容器overflow: hidden或contain: paint抑制了合并）
修复策略：解耦层级控制与合成控制
不要用合成手段解决层级问题，也不要用层级手段达成性能目标：
- 移除“保险式”提升：删掉所有非必要的
transform: translateZ(0)、will-change: transform，仅对真正需要动画的元素单独设置，并在动画结束后清除（例如el.style.willChange = 'auto'） - 用
contain: layout paint替代粗暴 z-index 提升：对模态框、下拉容器等独立功能区块启用 containment，既隔离布局影响，又避免子元素因 z-index 冲突被误升层 - 统一合成锚点：将动画/过渡效果集中在容器层（如轮播外层），子项只负责内容，禁用子项的 transform/z-index 组合；必要时用
transform: translateX(0)（2D）替代translate3d - 验证修复效果：修改后刷新页面，在 Layers 面板中确认图层数量下降、关键区域（如列表、导航栏）不再出现孤立小图层
