真正起效的前提是元素满足合成层触发条件且未被父级裁剪或降级；稳定触发方式包括transform: translatez(0)、opacity: 0.99、backface-visibility: hidden，而will-change仅在动画前几帧动态设置才有效。

直接加 will-change: transform 不等于“通知成功”——浏览器只把它当提示，不保证升层，更不保证显存预留。真正起效的前提是：元素已满足合成层触发条件，且未被父级裁剪或强制降级。

哪些 CSS 声明能稳定触发合成层并促使 GPU 预留缓冲区

不是所有“看起来像硬件加速”的写法都有效。Chromium 系列（Chrome、Edge、新版 Safari）实际依赖的是「图层提升规则」，而非 CSS 名称本身：

• transform: translateZ(0) 或 translate3d(0,0,0)：最稳妥的主动升层方式，兼容性好，且会立即创建独立纹理缓冲区
• opacity: 0.99：只要小于 1，就强制创建新图层（注意不能用 opacity: 1）
• backface-visibility: hidden：配合 3D transform 使用时，可避免背面纹理复用冲突，减少图层合并失败风险
• will-change: transform：仅在元素即将频繁变化前几帧设置才有效；提前太久（如页面加载时就设）会被浏览器忽略或延迟处理

反例：position: absolute; left: 0; + 动画更新 left 值 → 触发 Layout，根本不会升层，GPU 缓冲区压根不分配。

为什么设置了 will-change 却没看到显存缓冲区被预留

常见原因不是语法错，而是上下文破坏了合成前提：

• 父容器有 overflow: hidden，而子元素 transform 后超出裁剪区 → 浏览器放弃合成，回退到 CPU 绘制
• 同帧内既写 transform 又读 offsetHeight / getBoundingClientRect() → 强制同步布局（Layout Thrashing），中断合成流程
• 元素同时用了 filter: blur(2px) 和 opacity → 某些版本 Chromium 会合并图层，导致无法单独分配缓冲区
• 动画元素含高清 <img> 或 <canvas></canvas>，但未控制尺寸 → 单个图层缓冲区可能达 4K×4K×4 字节 ≈ 64MB，显存不足时浏览器静默降级

如何验证 GPU 是否真为该元素分配了独立缓冲区

不能只看 DevTools 的“Layers”面板是否显示图层——那只是逻辑层。要确认物理显存是否预留，得看运行时行为：

• 打开 Chrome DevTools → More Tools → Rendering → 勾选 “Layer Borders”：绿色边框 = 独立合成层；灰色边框 = 共享图层或未升层
• 同页面开启 “FPS Meter”，播放动画时观察右上角显存占用（Memory）：若持续 >80% 且帧率下降，说明缓冲区已分配但显存吃紧
• 用 chrome://gpu 页面确认 “Graphics Feature Status” 中 “Rasterization” 和 “Compositing” 是否为 Hardware accelerated
• 关键判断点：动画过程中滚动页面，若该元素出现撕裂、闪烁或掉帧，基本可断定它没走独立合成管线

真正难的不是“怎么写”，而是让整个渲染链路不打断合成——哪怕一个 scrollHeight 读取，都可能让前面所有 will-change 白设。