硬件加速的关键是将动画卸载至合成线程而非依赖gpu更快，transform和opacity能创建独立复合层，仅触发composite跳过layout与paint；left等属性则强制全流程渲染。
硬件加速让动画绕开重排重绘
关键不是“GPU更快”，而是浏览器把动画从主线程卸载到了合成线程。当使用 transform 或 opacity 时，浏览器会为该元素创建独立的复合层（Compositing Layer），后续位移、缩放、透明度变化都只在 GPU 中合成图层，完全跳过 Layout 和 Paint 阶段。
对比用 left 动画：每次修改都会触发 reflow（重排）→ repaint（重绘）→ composite，尤其在低端 Android WebView 中，一帧内多次重排直接堵死主线程；而 transform: translateX(100px) 只是挪动已有图层，GPU 合成器几毫秒就完成。
哪些 CSS 属性能真正触发硬件加速
只有特定属性能走合成路径，混入其他属性会整段降级回 CPU 渲染：
-
transform（含translate、scale、rotate，但不含matrix等非标准写法） opacity- 带 3D 上下文的属性（如
translateZ(0)、translate3d(0,0,0)、perspective）——本质是“骗”浏览器建图层 -
filter（部分滤镜，如blur()，但复杂链式滤镜可能回退）
以下写法会失效：transition: all 0.3s、transition: left, transform 0.3s、transform + box-shadow 同时动画。
translate3d(0,0,0) 和 will-change 不是万能药
它们的作用是“提前提升图层”，但现代浏览器（Chrome 80+ / Safari 14+）已能智能判断何时建层，盲目加反而有害：
-
translate3d(0,0,0)在老 Android 4.4 WebView 中仍有价值，但新环境基本不需要；它会增加内存占用，列表项滥用易引发 OOM -
will-change: transform必须动态控制：JS 在touchstart时设el.style.willChange = 'transform'，监听transitionend后立刻设回'auto'；静态写在 CSS 里（如.item { will-change: transform; }）极易图层爆炸 -
backface-visibility: hidden和perspective: 1000主要解决旧设备闪烁，新机型通常不需
JS 读取布局信息会悄悄破坏优化
哪怕 CSS 全写对了，只要动画过程中 JS 做了以下任一操作，就会强制同步布局（Forced Synchronous Layout），打断渲染流水线：
- 读取
offsetTop、getBoundingClientRect()、scrollHeight等返回布局信息的属性 - 读写交替（如先读
el.offsetTop，再改el.style.transform） - 在
requestAnimationFrame回调中混入布局读取
正确做法是：批量读取 → 批量写入；或用 ResizeObserver / IntersectionObserver 替代频繁 DOM 查询。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
