做前端动画时，很多人第一步会用setTimeout或者setInterval来循环改变元素位置，结果发现动画时快时慢，偶尔还会卡顿。问题的根源在于这类定时器的时间精度和浏览器渲染节奏对不上。浏览器为此提供了一个专门的接口——requestAnimationFrame，也就是常说的RAF。它会把回调函数挂到浏览器下一次重绘之前执行，天然与屏幕刷新率同步，是目前做DOM动画、Canvas绘制的首选方案。
RAF的执行时机与底层原理
要理解RAF为什么流畅，得先明白浏览器一帧里发生了什么。浏览器从接收任务到把画面呈现到屏幕上，大致经历这样几个阶段：执行JavaScript脚本、处理样式计算、布局、绘制、合成。整个过程由浏览器统一调度，一帧通常是16.6毫秒左右（对应60Hz的屏幕）。如果在布局和绘制之间有个专门的空隙留给开发者插入自定义逻辑，那就是RAF的执行窗口。
requestAnimationFrame接收一个回调函数作为参数，浏览器会在下一次重绘之前调用它。这个回调里你可以更新元素的样式、绘制Canvas内容，更新完成后浏览器紧接着就执行布局和绘制，逻辑修改和画面呈现被压缩在同一个帧周期内，不存在中间的空白状态，因此画面连贯。而setTimeout(fn, 16)只是把回调放进宏任务队列，具体什么时候执行取决于事件循环的繁忙程度，如果主线程被其他任务占用，回调就会被推迟，浏览器只能用旧画面凑数，肉眼看到的就是掉帧。
回调函数还会收到一个时间戳参数，表示RAF回调被触发的时间，单位是毫秒，精度高到微秒级。用这个参数计算动画进度，比自己在回调里调用Date.now()更准确，也更适合做基于时间的动画（time-based animation），保证动画速度在不同刷新率的屏幕上表现一致。比如在120Hz的屏幕上，RAF每秒会被调用约120次，在60Hz屏幕上是60次，如果动画每帧移动固定像素，高刷屏上动画会快一倍，用时间戳做差值计算就能避免这个问题。
RAF与setTimeout、setInterval的对比
三者的差异可以从几个维度看。第一是调度方式：setTimeout是宏任务，基于指定延迟入队；RAF由浏览器的渲染管线直接驱动，时机绑定在重绘之前。第二是精度：浏览器为了省电，后台标签页的定时器会被节流到最低一秒一次，而RAF在标签页不可见时直接停止回调，恢复可见时继续，既省资源又不会产生动画错乱。第三是掉帧风险：setInterval(fn, 16)不关心回调是否执行完毕，容易出现多次回调堆积，RAF则一次只注册一帧。
写法上RAF通常是递归调用式的，即回调内部再次注册下一次调用，这样保证上一次执行完成后再排队下一帧，不会出现任务堆积。基本骨架如下：
// RAF 动画基本骨架：把一个盒子从 0px 移动到 500px
function animate(timestamp) {
// timestamp 是浏览器传入的高精度时间戳
console.log('当前帧时间：', timestamp);
box.style.transform = 'translateX(' + progress + 'px)';
requestAnimationFrame(animate); // 递归注册下一帧
}
requestAnimationFrame(animate); // 启动动画
取消机制也不同。setTimeout用clearTimeout清除，RAF则用cancelAnimationFrame，并且要保存好返回的请求ID。这个ID是一个整数，多个RAF请求各自持有不同的ID，取消时需要指定对应的那个。做组件化开发时，组件销毁前忘记取消RAF是常见的内存泄漏和报错来源，值得特别注意。
实用代码示例与常见坑
先看一个基于时间戳的匀速动画，这是最推荐的写法。核心思路是记录开始时间，每帧根据流逝的时间计算进度，即使中间某些帧被跳过，元素最终也会到达正确位置：
const box = document.getElementById('box');
const DURATION = 1000; // 动画总时长 1000ms
const DISTANCE = 500; // 移动距离
let startTime = null;
function move(timestamp) {
if (startTime === null) startTime = timestamp; // 记录第一帧时间
const elapsed = timestamp - startTime; // 已流逝时间
const progress = Math.min(elapsed / DURATION, 1); // 归一化进度 0~1
box.style.transform = 'translateX(' + DISTANCE * progress + 'px)';
if (progress < 1) {
requestAnimationFrame(move); // 未结束，继续下一帧
}
}
requestAnimationFrame(move);
再看一个计算实时帧率的例子，常用于性能调试。思路是统计最近一秒内回调执行的次数，也可以用相邻两帧时间戳的差值换算：
let lastTime = performance.now();
let frameCount = 0;
function fpsLoop(now) {
const delta = now - lastTime;
frameCount++;
if (delta >= 1000) {
// 每满一秒输出一次帧率并重置
console.log('FPS:', Math.round(frameCount * 1000 / delta));
frameCount = 0;
lastTime = now;
}
requestAnimationFrame(fpsLoop);
}
requestAnimationFrame(fpsLoop);
使用RAF有几个容易踩的坑。其一是回调里不要做耗时超过16毫秒的重活，比如大量同步计算或长循环，否则这一帧被撑爆，照样掉帧，重计算应该拆分或交给Web Worker。其二是尽量在回调中修改transform、opacity这类不触发重排的属性，避免频繁读写offsetHeight等强制同步布局的属性。其三是RAF回调执行时 DOM 还是旧的布局状态，如果在回调里先读布局再写样式，可能引发布局抖动，读写应该分开批量处理。
在React等框架里使用RAF同样要处理好生命周期。典型做法是在useEffect中启动动画，清理函数中调用cancelAnimationFrame：
useEffect(() => {
let rafId;
const tick = (t) => {
setAngle((t / 10) % 360); // 根据时间戳更新旋转角度
rafId = requestAnimationFrame(tick);
};
rafId = requestAnimationFrame(tick);
return () => cancelAnimationFrame(rafId); // 组件卸载时取消
}, []);
总结一下，RAF的本质是把开发者代码挂载到浏览器渲染管线的重绘节点上，让动画逻辑和画面更新同频。对于CSS动画和Web Animation API覆盖不了的场景，比如Canvas游戏、数据可视化、打字机效果、自定义交互反馈，requestAnimationFrame配合时间戳做基于进度的计算，是兼顾流畅性和兼容性的标准答案。掌握它的执行时机、取消机制和性能边界，写出的动画才能真正达到丝滑的效果。
requestAnimationFrameRAFJavaScript动画修改时间：2026-09-05 22:18:53