requestAnimationFrame比setTimeout更可靠，因其自动对齐60fps渲染节奏；应记录performance.now()起始时间、避免强制同步布局、启用硬件加速并减少裁剪计算。
用 requestAnimationFrame 做平滑动画比 setTimeout 更可靠
浏览器渲染帧率通常为 60fps，requestAnimationFrame 会自动对齐这一节奏，而 setTimeout(fn, 16) 只是“尽力而为”，实际执行时机受 JS 主线程阻塞影响，容易掉帧或抖动。
实操建议：
- 始终把动画逻辑写在
requestAnimationFrame回调里，不要嵌套多层setTimeout - 动画开始前先记录起始时间（
performance.now()），避免用new Date()——精度低且可能被系统时钟调整干扰 - 每次回调中只做计算 + 修改样式，不触发强制同步布局（比如读取
offsetTop后立刻改style.left）
let startTime = null;
const animate = (timestamp) => {
if (!startTime) startTime = timestamp;
const elapsed = timestamp - startTime;
const progress = Math.min(elapsed / 1000, 1); // 1秒完成
element.style.transform = `translateX(${progress * 200}px)`;
if (progress < 1) requestAnimationFrame(animate);
};
requestAnimationFrame(animate);CSS transition 和 transform 配合最省心
纯 CSS 动画在大多数场景下性能更好、代码更短，尤其适合状态切换类动效（如展开/收起、悬停反馈）。关键在于：只对 transform 和 opacity 做过渡，这两者能走合成层，不触发重排重绘。
常见错误现象：
- 给
left/top加transition→ 每次都触发 layout，卡顿明显 - 在 class 切换后立刻读取
offsetHeight→ 强制同步布局，打断动画流水线 - 没加
will-change: transform（仅对复杂动画必要）→ GPU 提前准备不足，首帧延迟
.box {
transition: transform 0.3s ease, opacity 0.3s ease;
}
.box.active {
transform: translateX(100px) scale(1.1);
opacity: 0.8;
}用 Element.animate() 控制复杂关键帧动画
当需要多段变化、暂停/播放、精确时间控制（比如和音频同步），原生 Element.animate() 是比手写 requestAnimationFrame 更简洁的选择，且自带缓动、迭代、填充模式支持。
使用场景：
- 图标脉冲、加载旋转、路径描边动画
- 需要响应用户交互暂停/反向播放的动效
- 多个属性同时按不同曲线变化（如位移+缩放+透明度）
注意点：
-
animate()返回的Animation对象必须保存引用，否则会被 GC，动画立即停止 - Chrome/Firefox 支持良好，Safari 16.4+ 才完整支持
iterationStart等高级参数 - 避免在循环中反复调用
animate()创建新实例，应复用或调用cancel()+play()
const anim = element.animate(
[
{ transform: 'scale(1)', opacity: 1 },
{ transform: 'scale(1.2)', opacity: 0.5 }
],
{
duration: 600,
easing: 'cubic-bezier(0.34, 1.56, 0.64, 1)',
fill: 'forwards'
}
);
// 后续可控制
anim.pause();
anim.reverse();动画卡顿？先查是否触发了 Layout 或 Paint
90% 的“动画慢”问题不是代码写得不够快，而是无意中让浏览器做了大量额外工作。用 Chrome DevTools 的 **Rendering > Paint flashing** 和 **Layers** 面板能快速定位。
典型诱因：
- 动画中读取
offsetWidth、getBoundingClientRect()、computedStyle→ 触发强制同步布局 - 频繁修改
innerHTML或添加 DOM 节点 → 触发重排 - 用
background-image做渐变动画 → 每帧都触发 Paint，且无法硬件加速 - 元素没有独立合成层（缺少
transform: translateZ(0)或will-change）→ 在主图层上绘制，拖慢整页
一个容易被忽略的点：动画元素的父容器如果有 overflow: hidden 且子元素超出，每次 transform 变化都可能触发额外裁剪计算。能不用就不用。
