只有transform和opacity能真正触发合成层提升，因二者可绕过layout和paint交由gpu合成器处理；其他如left、top、width等均强制触发重排重绘。
哪些 CSS 属性能真正触发合成层提升
只有 transform 和 opacity 的变更能绕过 Layout 和 Paint，交由 GPU 合成器直接处理。其他看似“动效”的写法，比如 left/top、width、height、background-position，都会强制触发重排或重绘，完全无法进入合成管线。
注意：transform: translate3d(0, 0, 0) 本身不比 translateY(0) 更快，它唯一作用是“骗”浏览器创建独立图层——但前提是该元素没被父级的 stacking context 截断（例如父级有 opacity: 0.99 或 will-change: opacity 就可能合并图层）。
-
filter和backdrop-filter会禁用硬件加速，哪怕只加filter: blur(0.1px)也足以让图层降级 -
will-change: transform是预声明，不是万能开关；滥用会导致图层提前创建、内存浪费，且对已静止元素长期生效反而有害 - 动画中混用
transform和opacity是安全的，但一旦加上filter，整个图层就回退到 CPU 渲染
为什么 translateZ(0) 有时失效
根本原因不是写法错，而是浏览器的图层合并策略在起作用。当两个相邻动画元素都用了 transform: translateZ(0)，且它们没有明确的 stacking context 隔离，Chrome 可能将它们合并进同一个合成层——这省显存，但一旦其中一个要缩放、另一个要透明度渐变，就会互相干扰，甚至卡顿。
真正可控的提升方式是主动构造 stacking context：
- 给目标元素加
isolation: isolate（最干净，无副作用） - 或用
transform: translateZ(0) scale(1)（双属性确保不被合并） - 避免父容器设置
overflow: hidden+transform组合，这在旧版 Chromium 中会意外抑制子元素图层提升
大规模动画下显存暴涨的隐性来源
每个合成层在 GPU 显存中至少占用一块 4K × 4K × 4 字节缓冲区（≈64MB）。如果你用 will-change 提前为 10 个图片卡片声明提升，即使它们当前静止，显存也已分配——这不是延迟加载，是立即占坑。
更危险的是：含高清图、SVG 或 <canvas></canvas> 的元素，其图层缓冲区会按实际像素尺寸分配，不是按 CSS 尺寸。一张 8000×6000 的图片放进 200×150 的容器里，GPU 仍按原图分辨率建图层。
- 动画结束立即移除
will-change（可用animationend事件监听后清除） - 对列表类动画，用虚拟滚动 + 动态
transform提升，别一次性全提 - 用
chrome://gpu查看 “Compositing” 模块是否显示 “Hardware accelerated”，再配合 “Rendering” 面板观察 “Layers” 数量变化
如何验证图层是否真的被提升
不能只看动画是否流畅——CPU 渲染也能凑出 60fps（靠丢帧），必须确认是 GPU 在干活。
打开 chrome://flags，启用 rendering-frame-rate 并重启，然后按 Shift+Cmd+P（Mac）或 Shift+Ctrl+P（Win）调出命令菜单，输入 “Layers” 打开图层面板。悬停在元素上，能看到实时图层 ID、尺寸、是否 GPU-backed。
- 若显示 “Software Composited” 或 “CPU rasterized”，说明提升失败
- 若图层尺寸远大于视口（如 8000×6000），说明图片未压缩或未用
image-rendering: pixelated降采样 - 多个小元素共用一个大图层（Layer ID 相同），说明隔离失败，需补
isolation: isolate
will-change 和未约束高分辨率资源的图层尺寸。
