强制提升合成层需谨慎：它用显存换帧率，易致层爆炸和显存溢出；仅满足浏览器图层提升规则的写法（如translate3d、will-change）才真正创建独立合成层，且须适时撤销以防内存泄漏。
能强制提升合成层，但必须清楚：这不是“开个开关就加速”，而是用显存换帧率，且极易引发层爆炸和显存溢出。
哪些 CSS 触发方式真正创建独立合成层
只有明确满足浏览器图层提升规则的写法，才会分配 GPU 显存缓冲区。常见误区是以为 transform: translateX(0) 或 opacity: 0.99 就够了——其实它们只是“可能”触发，是否真提升取决于父级堆叠上下文、是否被遮挡、是否含不可合成属性等。
-
transform: translateZ(0)、transform: translate3d(0, 0, 0)是最稳定的方式，强制创建新堆叠上下文并提升为合成层 -
will-change: transform是声明式提示，但仅在元素即将动画前生效；若长期设置，Chrome 会提前分配显存并可能不释放 -
opacity单独使用可提升，但一旦和filter、backdrop-filter、mask等混用，合成层会被降级回 CPU 渲染 -
position: fixed+z-index高值 ≠ 合成层；它只影响层叠顺序，不触发提升
为什么 translate3d(0,0,0) 不等于“性能提升”
它只是兜底创建合成层的手段，本身不带来任何计算优势。实测中，加了 translate3d 却未做后续动画，反而因多占一块 ~64MB 显存（4K×4K RGBA 缓冲）而拖慢首屏渲染。更危险的是：如果该元素内部含高清 <img>、<canvas> 或复杂 SVG，显存占用会翻倍增长。
- 每个合成层至少占用一块独立 GPU 缓冲区，与分辨率强相关
- Chrome DevTools → Layers 面板可直观查看每个层的尺寸和内存估算
- 移动端或集成显卡设备上，5–8 个大尺寸合成层就可能触发显存告警甚至崩溃
如何安全批量提升多个动画元素
不要给每个动效元素单独加 translate3d。浏览器对“相邻同类型动画元素”有层合并优化，强行拆分反而破坏该机制。
- 把需同步动画的 DOM 节点包裹进一个容器，对该容器应用
transform或will-change，让子元素自然继承合成上下文 - 避免在
:hover或滚动监听中动态加translate3d—— 这会导致频繁创建/销毁图层，引发卡顿 - 用
getComputedStyle(el).transform检查是否真进入合成管线，而非仅靠开发者工具 Layers 面板判断 - 动画结束立即移除
will-change，否则 Chrome 会持续保有该层（即使元素已静止）
真正难的不是“怎么提”，而是“提多少、提谁、什么时候撤”。合成层一旦分配，GPU 显存不会自动回收，尤其在单页应用反复切换视图时，容易累积成隐形内存泄漏。
