合成层本身不省显存，滥用反而暴涨；关键在于精准控层与及时卸载，需通过Layers面板定位爆点、避免隐式升层、合理使用will-change、彻底清理虚拟滚动残留，并与RAF动画节奏对齐。
直接结论：合成层本身不省显存，滥用反而暴涨；关键不是“提层”，而是“精准控层+及时卸载”。
怎么用 Layers 面板快速定位显存爆点
打开 Chrome DevTools → More Tools → Layers（不是“Rendering”里的勾选项），滚动/触发动画后观察图层树。每条蓝色高亮条代表一个合成层，右侧显示尺寸与内存估算，例如 1920×1080 @4B = ~7.5MB。点击某层，对应 DOM 节点会高亮——重点检查这些：
- 是否是静态卡片、文字块、未动画的
.header或.footer被误提升 - 是否存在嵌套 3D 变换：父级
perspective+ 子级rotateY→ 触发隐式多层叠加 - 是否有大量
will-change: transform持久存在，且元素早已停止动画
为什么 translate3d(0,0,0) 比 translateX(0) 更危险
translate3d(0,0,0) 是强触发合成层的“核按钮”，浏览器几乎无条件升层；而 translateX(0) 在现代 Chromium 中同样可触发合成，但更轻量、更可控，且不会强制启用 z-axis 管理开销。
- 3D 变换会激活额外的深度缓冲区和矩阵计算路径，显存占用翻倍（尤其含高清图片时）
- 移动端 WebView 或低端 GPU 上，
translate3d可能降级为软件绘制，反而更卡 - 替代方案：用
transform: translateX(0) scale(1)替代translate3d(0,0,0)，效果一致，风险更低
JS 动画中 will-change 的正确开关时机
will-change: transform 不是“设了就完事”的优化开关，它只是个提示，真正起效的前提是：元素已脱离常规渲染流，且 JS 不再读取布局属性（如 offsetWidth、getBoundingClientRect()）。
- ✅ 正确做法：动画开始前 JS 动态设置
el.style.willChange = 'transform' - ✅ 动画结束后监听
animationend或transitionend，立即执行el.style.willChange = 'auto' - ❌ 错误做法：全局 CSS 写死
.item { will-change: transform }，尤其对长列表中 90% 不动的 item - ⚠️ 注意：若动画过程中 JS 同步读取了
scrollHeight或触发了强制同步布局，will-change不仅无效，还会加重合成器负担
虚拟滚动里合成层残留怎么清
虚拟滚动卸载 item 时，仅设 display: none 或 visibility: hidden 不够——DOM 节点还在，其合成层可能滞留 GPU 显存中，持续占用数 MB 空间。
- 必须彻底移除节点：
container.removeChild(itemEl)，或用replaceChildren()清空并重建 - 配合
contain: paint在滚动容器上声明，限制浏览器渲染边界，防止子元素意外升层 - 验证方式：Layers 面板中反复滚动 → 观察图层数量是否稳定在个位数（如 5–8 层），而非随滚动持续增长至 50+
最易被忽略的一点：合成层优化不是独立动作，它必须和 JS 动画节奏对齐——requestAnimationFrame 更新 transform 的同时，另一段代码若在同帧内读取了布局信息，整个提层逻辑就失效，还白占显存。
