CSS动画和Web Animations API相比哪种性能更优？

真正GPU加速的CSS属性只有transform和opacity；其他如box-shadow、filter、border-radius等仍依赖CPU绘制易掉帧，性能瓶颈在于属性选择而非API类型。

性能没有绝对优劣，关键看用法是否触发合成层。正确使用 transform 和 opacity 时，两者都能稳定跑满 60fps；但一旦误改 width、left 或 background-color，CSS 动画会强制触发布局+重绘，而 Web Animations API 同样逃不掉——性能瓶颈不在 API 类型，而在属性选择。

哪些 CSS 属性能真正 GPU 加速？

只有少数属性修改时能跳过主线程，直接交由合成器线程处理：

• transform（含 translate、scale、rotate）
• opacity

其他看似“视觉相关”的属性如 box-shadow、filter（尤其是 blur()）、border-radius，在多数设备上仍需 CPU 绘制，容易掉帧。例如 filter: blur(40px) 在中低端 Android 上可能直接卡顿到 20fps。

Web Animations API 的真实控制优势在哪？

不是更快，而是更可控——尤其在运行时需要动态响应的场景：

立即学习“前端免费学习笔记（深入）”；

• 用户拖拽过程中实时调整 animation.currentTime，实现“跟手”反馈
• 用 animation.pause() + animation.play() 实现播放/暂停按钮，无需切换 class 或重写 CSS 变量
• 多个动画同步：调用 document.getAnimations() 统一管理全部动画进度，避免时间偏移
• 动态生成关键帧：比如根据屏幕尺寸计算 translateX 偏移量，直接传入 animate()，不用预设 N 个 media query 版本

为什么你写的 CSS 动画还是卡？

常见误操作远比 API 选型更致命：

• 写了 transition: all 0.3s —— 任意属性变更都触发过渡，包括意外修改的 height 或 margin
• 在 @keyframes 里用了 top/left，而不是 transform: translateY()
• 没加 will-change: transform，导致浏览器无法提前准备合成层（尤其首次动画）
• 动画元素父容器设置了 overflow: hidden 且子元素有 transform，某些 Safari 版本会降级到软件渲染

真正容易被忽略的点是：WAAPI 的 animate() 返回的 Animation 对象自带生命周期事件（onfinish、oncancel），但很多人直接丢弃引用，导致动画结束后 DOM 状态残留、内存泄漏——这比选错 API 更常引发线上问题。