真正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 更常引发线上问题。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
