合成层优化需精准触发：仅对满足transform/opacity动画、position:fixed、video等条件的元素创建合成层；滥用will-change或translateZ(0)会导致内存浪费和性能下降，应结合DevTools图层面板监控层数，优先控制在20层以内。
合成层优化不是加了 will-change 就万事大吉，多数卡顿问题反而因它而起。
哪些元素该进合成层？看动画触发条件，不是看“看起来动得快”
浏览器只对满足特定条件的元素创建独立合成层：有 transform 或 opacity 动画、position: fixed、video、iframe，或显式设置了 will-change: transform / will-change: opacity。但注意：
-
will-change是提示，不是指令——浏览器可能忽略，也可能提前分配资源；滥用会导致内存浪费甚至更慢 - 仅靠
transition: left 0.3s不会进合成层，left触发 layout → paint → composite 全流程，比transform: translateX()慢 3 倍以上 - 轮播图、下拉菜单、弹窗遮罩层这些高频交互区域，优先用
transform: translateZ(0)或transform: scale(1)强制分层，而非改top/left
怎么查当前页面有多少合成层？别猜，用 DevTools 看真实图层树
Chrome / Edge 开发者工具中打开 Layers 面板（需在 More Tools → Rendering 中勾选 “Layer borders” 和 “FPS meter”），滚动或触发动画后观察：
- 每块带边框的彩色区域 = 一个合成层；颜色越深通常表示层级越深或更新越频繁
- 如果某张图片、文字块单独成层，但又没动画，大概率是误用了
will-change或冗余transform - 顶部状态栏显示 “Compositing layers: X”，超过 20 层就该警惕——移动端 GPU 内存有限，超限会降帧或强制回退到 CPU 绘制
transform: translateZ(0) 和 will-change: transform 到底怎么选？
两者目的都是触发合成层，但时机和可控性完全不同：
立即学习“前端免费学习笔记（深入）”；
-
translateZ(0)是“硬触发”：只要样式生效，立刻建层，无条件，不回收；适合已知会长期动画的容器（如轮播外层.carousel-wrapper） -
will-change是“软提示”：告诉浏览器“接下来可能变”，浏览器决定是否建层、何时建、何时销毁；适合临时交互（如 hover 时放大按钮），但必须配合 JS 在交互结束后清除：element.style.willChange = 'auto' - 千万别对列表项（
.item）批量加will-change—— 100 个 item 就可能生成 100 个图层，内存暴涨且毫无必要
合成层之间互相遮挡时，z-index 还管用吗？
管用，但逻辑变了。合成层有自己的绘制顺序（paint order），z-index 只在**同一合成层内**生效；跨层时，由图层创建顺序和 transform-style 决定叠放关系：
- 后创建的合成层默认在前（比如 JS 动态插入的弹窗层会盖住早先的轮播层）
- 父容器设了
transform-style: preserve-3d，子元素即使有transform也不会升层，z-index仍按 DOM 顺序作用 - 最稳妥的方式：把需要叠加控制的元素统一归到同一个合成层里（例如都加
transform: translateZ(0)到父容器），再用z-index调序
真正难的是平衡——既要让动画跑在 GPU 上，又不能让图层数失控。很多团队调优到最后，删掉的 will-change 比加上的还多。
