requestAnimationFrame 比 setTimeout 更适合动画，因其自动对齐屏幕刷新节奏、避免掉帧卡顿、后台自动暂停省电、优先级更高且可自适应降帧；需递归调用并显式取消以防泄漏。

requestAnimationFrame 为什么比 setTimeout 更适合做动画

因为 requestAnimationFrame 是浏览器专门为动画设计的 API，它会自动对齐屏幕刷新节奏（通常是 60Hz），而 setTimeout 的执行时机不可控，容易导致掉帧、卡顿或“撕裂”现象。

关键区别在于：浏览器知道你正在做动画，所以会在下一帧绘制前精准调度回调；setTimeout 只是“尽可能快地等指定毫秒后执行”，但这个“等完”可能刚好错过当前帧，被迫推到下下帧，造成不稳定的间隔（比如本该 16ms 一帧，结果变成 12ms + 20ms 交替）。

• requestAnimationFrame 在页面被切换到后台时自动暂停，省电节能；setTimeout 仍会持续触发，浪费资源
• 即使你写 setTimeout(fn, 16)，实际延迟受 JS 主线程阻塞影响，可能严重滞后；requestAnimationFrame 则由浏览器底层调度，优先级更高
• 部分低端设备或高负载场景下，requestAnimationFrame 会自动降帧（如降到 30fps），而 setTimeout 强行维持 16ms 间隔反而更容易卡死

怎么用 requestAnimationFrame 写一个基础动画循环

核心是递归调用自己 —— 每次回调结束前，再请求下一帧。不能用 for 或 while 硬循环，否则会阻塞渲染。

function animate() {
  // 更新状态：比如修改元素的 left/top/transform
  element.style.transform = `translateX(${x}px)`;
// 渲染后，请求下一帧
requestAnimationFrame(animate);
}
// 启动动画
let x = 0;
requestAnimationFrame(animate);

注意：requestAnimationFrame 不传时间戳参数也能运行，但推荐接收以支持基于时间的动画（避免因帧率波动导致速度不一致）：

function animate(timestamp) {
  if (!lastTimestamp) lastTimestamp = timestamp;
  const delta = timestamp - lastTimestamp; // 单位：毫秒
  x += delta * 0.5; // 每毫秒移动 0.5px，真正匀速
  lastTimestamp = timestamp;
element.style.transform = translateX(${x}px);
requestAnimationFrame(animate);
}
let lastTimestamp = 0;
requestAnimationFrame(animate);

常见错误：忘记取消动画或状态没清理

动画不是一次性任务，必须能随时停止，否则内存泄漏、CPU 持续占用、后台页签耗电——这是 requestAnimationFrame 最常被忽视的风险点。

• 每次调用 requestAnimationFrame 都返回一个整数 ID，要用 cancelAnimationFrame(id) 显式取消
• 如果动画绑定在某个组件上（比如 React 组件卸载、Vue 实例销毁），必须在 cleanup 阶段调用 cancelAnimationFrame
• 不要在每次动画帧里重复添加事件监听器或创建新定时器，状态应复用而非叠加

例如，在 Vue 的 onUnmounted 或 React 的 useEffect 清理函数中：

let animationId = null;
function animate() {
// ... 动画逻辑
animationId = requestAnimationFrame(animate);
}
onMounted(() => {
animationId = requestAnimationFrame(animate);
});
onUnmounted(() => {
if (animationId) {
cancelAnimationFrame(animationId);
}
});

什么时候其实不该用 requestAnimationFrame

不是所有“动起来”的需求都适合它。比如：

• 只需要一次性的过渡效果（如按钮点击反馈），用 CSS transition 更轻量、硬件加速、无需 JS 控制
• 需要精确控制毫秒级延迟（如音频同步、游戏逻辑 tick），requestAnimationFrame 的时间不可靠，得结合 performance.now() 手动校准
• 动画逻辑极简单且帧率不敏感（比如每秒更新一次倒计时），setInterval 足够，加 requestAnimationFrame 反而增加复杂度

真正考验判断力的地方，往往不在“怎么写”，而在“要不要写”——浏览器原生动画能力、CSS 的 transform & will-change、甚至纯 GPU 加速的 canvas 渲染，都可能比手写 JS 动画更合适。别让 requestAnimationFrame 成为条件反射式的默认选项。