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)`;
<p>// 渲染后，请求下一帧
requestAnimationFrame(animate);
}</p><p>// 启动动画
let x = 0;
requestAnimationFrame(animate);</p>注意：requestAnimationFrame 不传时间戳参数也能运行，但推荐接收以支持基于时间的动画（避免因帧率波动导致速度不一致）：
立即学习“Java免费学习笔记（深入）”；
function animate(timestamp) {
if (!lastTimestamp) lastTimestamp = timestamp;
const delta = timestamp - lastTimestamp; // 单位：毫秒
x += delta * 0.5; // 每毫秒移动 0.5px，真正匀速
lastTimestamp = timestamp;
<p>element.style.transform = <code>translateX(${x}px)</code>;
requestAnimationFrame(animate);
}
let lastTimestamp = 0;
requestAnimationFrame(animate);</p>常见错误：忘记取消动画或状态没清理
动画不是一次性任务，必须能随时停止，否则内存泄漏、CPU 持续占用、后台页签耗电——这是 requestAnimationFrame 最常被忽视的风险点。
- 每次调用
requestAnimationFrame都返回一个整数 ID，要用cancelAnimationFrame(id)显式取消 - 如果动画绑定在某个组件上（比如 React 组件卸载、Vue 实例销毁），必须在 cleanup 阶段调用
cancelAnimationFrame - 不要在每次动画帧里重复添加事件监听器或创建新定时器，状态应复用而非叠加
例如，在 Vue 的 onUnmounted 或 React 的 useEffect 清理函数中：
let animationId = null;
<p>function animate() {
// ... 动画逻辑
animationId = requestAnimationFrame(animate);
}</p><p>onMounted(() => {
animationId = requestAnimationFrame(animate);
});</p><p>onUnmounted(() => {
if (animationId) {
cancelAnimationFrame(animationId);
}
});</p>什么时候其实不该用 requestAnimationFrame
不是所有“动起来”的需求都适合它。比如：
- 只需要一次性的过渡效果（如按钮点击反馈），用 CSS
transition更轻量、硬件加速、无需 JS 控制 - 需要精确控制毫秒级延迟（如音频同步、游戏逻辑 tick），
requestAnimationFrame的时间不可靠，得结合performance.now()手动校准 - 动画逻辑极简单且帧率不敏感（比如每秒更新一次倒计时），
setInterval足够，加requestAnimationFrame反而增加复杂度
真正考验判断力的地方，往往不在“怎么写”，而在“要不要写”——浏览器原生动画能力、CSS 的 transform & will-change、甚至纯 GPU 加速的 canvas 渲染，都可能比手写 JS 动画更合适。别让 requestAnimationFrame 成为条件反射式的默认选项。
