rAF 比定时器更适合动画，因其在浏览器下一次重绘前执行、与刷新率同步、页面不可见时自动暂停、避免掉帧且对齐渲染管线。
JavaScript 动画的核心在于**平滑、稳定、低开销地更新画面**，而 requestAnimationFrame（简称 rAF）正是浏览器专门为动画设计的 API，它比 setTimeout 或 setInterval 更精准、更节能、更契合浏览器渲染机制。
为什么 rAF 比定时器更适合动画？
rAF 会把回调函数安排在**浏览器下一次重绘之前执行**，通常与屏幕刷新率同步（如 60Hz 下约每 16.7ms 一次）。它自动处理以下关键问题：
- 页面不可见时（如切换标签页），rAF 会暂停调用，节省 CPU 和电量
- 避免因 JS 执行延迟导致的“掉帧”，保证动画节奏稳定
- 与 CSS 渲染管线对齐，减少强制同步布局（layout thrashing）风险
基础 rAF 动画写法（带终止控制）
不能只调一次 rAF，要形成“递归调用链”。关键点是：每次执行完动画逻辑后，主动再请求下一帧。
let animationId = null;
function animate() {
// 1. 更新状态（如位置、透明度）
update();
// 2. 渲染（如修改 style、transform）
render();
// 3. 请求下一帧 —— 放在最后，且需保存 ID 以便停止
animationId = requestAnimationFrame(animate);
}
// 启动
animationId = requestAnimationFrame(animate);
// 停止（例如用户交互触发）
function stopAnimation() {
if (animationId) {
cancelAnimationFrame(animationId);
animationId = null;
}
}
用 rAF 优化性能的关键实践
光用 rAF 不等于高性能。真正起作用的是配合以下习惯：
立即学习“Java免费学习笔记（深入）”；
- 批量读写分离：先集中读取 offsetTop / getComputedStyle 等触发 layout 的属性，再集中写入 style / transform；避免“读-写-读-写”造成多次回流
- 优先使用 transform 和 opacity：这两个属性能走合成层（compositor layer），不触发布局和绘制，仅由 GPU 处理
- 避免在 rAF 回调里做耗时计算：复杂物理运算、大量 DOM 遍历、JSON 解析等应提前算好或用 Web Worker 分离
- 按需激活动画：对不在视口内的元素暂停其 rAF 循环，用 IntersectionObserver 配合控制
对比 setTimeout 的典型陷阱
下面这段代码看似“每 16ms 执行一次”，实际可能严重掉帧：
// ❌ 危险：时间间隔固定，不随帧率自适应
setTimeout(() => {
update();
render();
setTimeout(arguments.callee, 16);
}, 16);
问题包括：即使上一帧卡顿，下一帧仍强行触发；后台标签页中仍在跑，白耗资源；无法与显示器垂直同步（VSync），易出现撕裂或抖动。
