rAF是浏览器渲染流水线中固定时机的高优先级执行点，位于样式计算后、布局前，确保动画更新不触发强制同步布局；setTimeout无法替代，因其受宏任务队列延迟影响且后台不停止；需配合DevTools验证执行位置与性能。
浏览器重绘机制与定时器回调的协作，本质是“谁该在什么时候干活”的调度问题。rAF 不是另一个定时器，而是浏览器渲染流水线里一个有明确位置、有固定时机的执行点——它只在下一帧绘制开始前被调用，且由浏览器内核统一安排，不依赖 JavaScript 任务队列。
rAF 的执行时机嵌入渲染流水线
rAF 回调不是插在 setTimeout 队列里等空闲，而是被浏览器放进一个独立的“动画帧回调队列”，这个队列会在每帧的样式计算之后、布局之前被执行（部分浏览器可能微调顺序，但始终在绘制前）。这意味着：
- 你的动画逻辑（比如更新 transform、opacity）能赶在浏览器做 layout 和 paint 之前完成，避免强制同步布局（forced synchronous layout）
- 如果一帧内多次调用 rAF，浏览器只会保留最后一次注册的回调（类似事件去重），不会累积执行
- 回调接收的时间戳（timestamp）是自页面加载起的高精度毫秒数，可用于计算帧间隔或做时间敏感的插值
为什么 setTimeout/setInterval 无法替代 rAF
它们的触发时机和调度层级完全不同：
- setTimeout 回调进入的是宏任务队列，必须等当前 JS 执行栈清空 + 本轮事件循环结束 + 下一轮循环开始后才可能执行，实际延迟不可控
- 即使设为 16ms，也可能因主线程繁忙而延迟几十毫秒，导致跳帧；而 rAF 总是尽力对齐屏幕刷新节奏（如 60Hz → ~16.67ms，120Hz → ~8.33ms）
- 页面切到后台时，setTimeout 仍会运行（消耗 CPU），rAF 则自动暂停，这是浏览器主动做的节流优化
rAF 与其它任务的优先级关系
浏览器内部有一套多优先级任务调度系统，rAF 属于高优先级渲染任务，地位高于普通宏任务（如 setTimeout）、低于用户输入响应（如 pointermove、scroll）：
- 当用户快速滚动时，输入事件会被插队优先处理，rAF 可能被短暂推迟，但不会被丢弃
- 若 rAF 回调执行过久（如做了复杂计算或大量 DOM 修改），会挤占 layout/paint 时间，导致本帧超时、掉帧
- 建议在 rAF 回调中只做必要更新，把耗时操作拆到 requestIdleCallback 或 Web Worker 中
如何验证 rAF 是否按预期协作
不用猜，直接看 DevTools 的 Performance 面板：
- 录制一段动画操作，展开“Frames”轨道，观察每一帧的“Animation Frame Fired”标记是否规律出现
- 点击某帧，查看“Main”线程详情，确认 rAF 回调是否落在“Update Layer Tree”之前、“Layout”阶段之后
- 若发现 rAF 后紧跟着长任务（如 Recalculate Style 或 Layout），说明动画逻辑触发了重排，需改用 transform/opacity 等合成属性
