requestAnimationFrame + Web Animations API 更卡是因为误用触发重排或未满足GPU加速条件；正确做法是仅动画transform/opacity、用will-change/translate3d主动提示合成、复用Animation而非频繁新建。
为什么 requestAnimationFrame + Web Animations API 组合反而更卡
直接用 requestAnimationFrame 手动更新 CSS 属性（比如 transform）看似可控，但在 60fps 动画中频繁读写 offsetLeft、getComputedStyle 或触发重排，会把主线程拖垮。Web Animations API（WAAPI）本身不自动规避这些——如果你在 animate() 后立刻调用 animation.effect.getComputedTiming()，或在 onupdate 回调里查 DOM 尺寸，照样掉帧。
关键不是“用了 WAAPI 就省心”，而是它把动画逻辑移交给了合成器线程（compositor thread），前提是：动画属性可被硬件加速，且不触发样式计算回流。
- 只对
transform和opacity做动画（其他如width、left、color会强制同步样式计算） - 避免在
AnimationTimeline上监听onfinish或oncancel时执行复杂 JS（比如触发 Vue 响应式更新） - 不要用
animation.effect.updateTiming()频繁改 duration / easing —— 它会触发重同步，尤其在循环动画中
如何用 Element.animate() 触发 GPU 加速但不意外降级
不是所有 transform 都能进合成层。Chrome DevTools 的 “Layers” 面板能验证是否真上了 GPU，但更稳的方式是主动构造强提示：
- 给目标元素加
will-change: transform（仅动画前设置，动画结束立即移除，否则内存泄漏） - 用
translateZ(0)或translate3d(0,0,0)替代纯translateX/Y（某些旧版 Safari 对 2D transform 合成不积极） - 确保元素没有
overflow: hidden与圆角/阴影共存——这会让合成器放弃该图层，回落到主线程光栅化
示例：安全启动一个平移动画
const anim = el.animate(
[
{ transform: 'translate3d(0, 0, 0)', opacity: 1 },
{ transform: 'translate3d(100px, 0, 0)', opacity: 0.8 }
],
{
duration: 300,
easing: 'cubic-bezier(0.25, 0.46, 0.45, 0.94)',
fill: 'forwards'
}
);
// 动画开始后立即提升图层
el.style.willChange = 'transform';
anim.onfinish = () => el.style.willChange = 'auto';用 AnimationTimeline 实现时间轴解耦，避免 setInterval 干扰
高频动画常伴随节流逻辑（比如每 100ms 更新一次位置），若用 setInterval 驱动 Element.animate() 创建新动画实例，会造成动画对象堆积、GC 压力大、主线程抖动。正确做法是复用单个 Animation，靠自定义时间轴控制播放进度。
- 创建
DocumentTimeline（默认）或ScrollTimeline（滚动驱动）已足够；不用自己 newAnimationTimeline（目前仅 Chrome 支持，且非标准） - 用
animation.currentTime手动设值比play()/pause()更轻量，尤其配合requestIdleCallback做微调 - 避免在
scroll事件里直接改currentTime——加passive: true并用raf节流
典型误用：
// ❌ 每次 scroll 都新建动画，内存爆炸
window.addEventListener('scroll', () => {
el.animate(...);
});推荐写法：
// ✅ 复用一个动画，只推时间
const anim = el.animate([...], { duration: 1000, fill: 'forwards' });
let lastTime = 0;
function syncToScroll() {
const progress = window.scrollY / document.body.scrollHeight;
anim.currentTime = progress * 1000;
if (progress < 1) requestAnimationFrame(syncToScroll);
}
syncToScroll();性能陷阱：composite: 'replace' 与 'add' 的实际开销差异
composite 控制动画值如何与当前样式叠加。很多人以为 composite: 'add' 更“智能”，但它在合成器层需要额外计算（尤其是多个动画叠加时），反而增加 GPU 负担。高频场景下，'replace' 是唯一安全选项。
-
composite: 'replace'：直接覆盖当前 computed style，无叠加计算，最快 -
composite: 'add'：需读取当前值再相加，若当前值来自 layout（比如刚被 JS 修改过style.left），会强制同步回主线程取值 -
composite: 'accumulate'：仅用于 SVG 动画，Web 不支持，设了也忽略
特别注意：如果元素已有内联 style.transform，又用 composite: 'replace' 动画，结果是动画值完全取代内联值——这通常是期望行为；但若想“在现有 transform 上追加旋转”，必须先读取并解析 getComputedStyle(el).transform，手动拼接矩阵，再用 replace 写入——这种操作应尽量避免在动画循环中做。
真正需要复合动画的场景，优先考虑用多个独立 animate() 调用，各自控制不同属性（如一个控 translate，一个控 rotate），都设 composite: 'replace'，由浏览器内部合成器统一处理。
