requestAnimationFrame 能匹配 60FPS，因其在每帧重绘前执行回调，且浏览器以约16.67ms间隔刷新；正确用法包括节流调用、读写分离、移出耗时操作、结合观察者API，并避免与setTimeout混用或用setInterval替代。
requestAnimationFrame 是浏览器提供的原生 API，专为在下一次屏幕重绘前执行动画或 UI 更新而设计。它自动与显示器刷新率（通常是 60Hz）对齐，因此合理使用可稳定达成 60FPS，避免强制同步布局、重复渲染或掉帧。
为什么 requestAnimationFrame 能匹配 60FPS
现代浏览器通常以约 16.67ms（1000ms ÷ 60）为间隔触发一次重绘。requestAnimationFrame 会把回调函数排队到**下一个可用的渲染帧开始前**执行，且在该帧内完成 DOM 更新、样式计算、布局、绘制全过程。只要单次回调耗时 ≤16ms，就能维持流畅的 60FPS。
正确使用 requestAnimationFrame 更新 UI 的关键做法
- 只在需要时调用，避免连续无节制递归：不要在回调里无条件再次调用 rAF；应根据状态（如动画是否继续、数据是否变化）决定是否继续调度
- 批量读写分离：先读后写：避免在同一次 rAF 回调中交替读取 offsetTop/scrollTop 等布局信息和修改 class/style，否则触发“强制同步布局”（Layout Thrashing），大幅拖慢性能
- 把耗时操作移出 rAF 回调：复杂计算、大数据处理、网络请求等应放在 Web Worker 或用 setTimeout 分片，rAF 内仅做轻量级 DOM 更新
- 结合 IntersectionObserver 或 ResizeObserver 做按需更新：例如只对可视区域内的列表项触发动画，减少不必要的 rAF 调度
一个典型的安全更新模式示例
以下代码确保滚动中实时更新某元素位置，同时不卡顿：
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
let pendingUpdate = false;
const updateElement = () => {
// 仅更新依赖当前滚动位置的样式，不读取 offsetTop 等
element.style.transform = `translateY(${window.scrollY * 0.5}px)`;
};
<p>const scheduleUpdate = () => {
if (!pendingUpdate) {
pendingUpdate = true;
requestAnimationFrame(() => {
updateElement();
pendingUpdate = false;
});
}
};</p><p>// 在 scroll、resize 等高频事件中节流调用
window.addEventListener('scroll', scheduleUpdate);</p>这里用标志位防止同一帧多次注册，且 updateElement 中只做 transform（合成层操作），不触发重排。
常见误区与替代方案对比
- 不用 setInterval(, 16)：无法对齐刷新节奏，可能造成错帧、丢帧，且页面后台运行时仍计时
- 避免混用 setTimeout 和 rAF 更新同一状态：时序不可控，易导致视觉闪烁或状态竞争
- 服务端渲染（SSR）+ hydration 后，首次 UI 更新也建议用 rAF 包裹：让 DOM 准备就绪后再触发首帧动画，避免 FOUC 或 layout shift
掌握 requestAnimationFrame 的本质——它是浏览器渲染流水线的“预约入口”，不是通用定时器。围绕帧预算（≤16ms）、避免强制重排、保持更新原子性，就能自然获得稳定 60FPS 的异步 UI 表现。
