requestAnimationFrame 比 setTimeout 更适合动画，因其对齐屏幕刷新率、自动优化（如页面不可见时暂停）、无延迟累积、提供高精度时间戳；需递归调用、用 currentTime 计算进度、防超限、避免重复启动并及时取消，且不适用于重逻辑、纯CSS可替代场景或无DOM环境。
requestAnimationFrame 为什么比 setTimeout 更适合做动画
因为 requestAnimationFrame 是浏览器专门为此设计的 API，它会把动画帧对齐到屏幕刷新节奏（通常是 60Hz），而 setTimeout 只是“尽力而为”地按时间间隔执行，容易出现掉帧、卡顿或撕裂。
- 浏览器知道你正在做动画，可自动优化：比如页面不可见时暂停调用，节省 CPU 和电量
- 不会因 JS 执行阻塞而累积延迟（
setTimeout在长任务后可能连续触发多次来“追帧”） - 时间戳参数天然精确，避免手动用
Date.now()计算带来的误差
如何用 requestAnimationFrame 实现一个平滑移动动画
核心是递归调用自身，并在每次回调中更新状态、重绘，最后决定是否继续下一次帧。
let startTime = null; const duration = 2000; // 动画总时长 2s const fromX = 0; const toX = 300;function animate(currentTime) { if (!startTime) startTime = currentTime; const elapsed = currentTime - startTime; const progress = Math.min(elapsed / duration, 1);
// 线性插值 const x = fromX + (toX - fromX) * progress; document.getElementById('box').style.transform =
translateX(${x}px);if (progress < 1) { requestAnimationFrame(animate); } }
requestAnimationFrame(animate);
- 必须用
currentTime（而非Date.now()）计算进度，它是高精度时间戳，且与刷新同步 - 记得用
Math.min(..., 1)防止因微小延迟导致 progress 超过 1，造成抖动 - 不要在回调里做大量 DOM 查询或样式计算，否则可能拖慢帧率
常见误用：忘记取消动画或重复启动
比如在按钮点击中反复调用 requestAnimationFrame，但没保存上一次的 ID，会导致多个动画同时运行，CPU 升高、元素行为异常。
立即学习“Java免费学习笔记（深入）”；
- 用变量缓存当前动画 ID：
let animationId = null; - 开始前先取消已有动画：
if (animationId) cancelAnimationFrame(animationId); - 每次调用
requestAnimationFrame后赋值：animationId = requestAnimationFrame(...); - 组件卸载或条件不满足时，务必调用
cancelAnimationFrame(animationId)
requestAnimationFrame 不是万能的：什么情况不该用它
它只解决“何时执行”，不解决“怎么执行”。如果动画逻辑本身很重（比如每帧都深克隆大对象、重排版大量元素），照样卡顿。
- 纯 CSS 动画（
transition/@keyframes）更轻量，优先用在位移、缩放、透明度等合成属性上 - 需要精确控制时间轴（如音画同步、游戏帧逻辑）时，得结合
performance.now()和自定义调度 - 服务端渲染或无 DOM 环境（如 Node.js）里，
requestAnimationFrame根本不存在，需降级处理
真正难的不是调用这个函数，而是判断哪部分该进 GPU 合成层、哪部分该节流、哪部分该用 Web Worker 搬走——这些才是让动画丝滑的关键。
