requestAnimationFrame 本身不拆分任务，真正实现任务拆分需在单次回调中只处理少量工作并递归调度；否则超16ms将导致掉帧卡顿。
requestAnimationFrame 本身不拆分任务，它只是把代码调度到浏览器下一次重绘前执行；真正实现“任务拆分”的关键是：在单次 rAF 回调中只处理一小部分工作，把剩余工作留到下一个 rAF 继续执行——这样既保持动画流畅（不阻塞主线程），又避免长任务导致掉帧。
为什么不能直接在 rAF 里跑重逻辑？
如果一个 rAF 回调里做了大量计算、DOM 遍历或复杂布局读写，会超过 16ms（60fps 下的帧预算），浏览器来不及完成样式计算、布局、绘制、合成，就会跳帧。用户感知就是卡顿、抖动。
用 rAF 拆分长任务的典型模式
把原本一次性做完的大任务（比如处理 10000 个元素、解析大 JSON、渲染复杂图表）切成小块，每块控制在 2–5ms 内完成，然后交给下一个 rAF：
- 维护一个待处理队列（如数组、迭代器或索引计数器）
- 每次 rAF 只处理前 N 项（N 可固定，也可动态估算：用 performance.now() 测已耗时，快超限时就暂停）
- 若队列未空，递归调用 requestAnimationFrame 继续
- 避免用 setTimeout 或 setInterval 替代——它们不与刷新节奏同步，容易错失帧或造成不一致延迟
一个可复用的 rAF 分片执行工具函数
下面是一个轻量封装，支持自动节制执行节奏：
function scheduleInFrames(tasks, options = {}) {
const { batchSize = 20, maxTime = 4 } = options;
let i = 0;
const start = performance.now();
<p>function frame() {
const now = performance.now();
// 如果已接近时间上限，先交还控制权
if (now - start > maxTime && i < tasks.length) {
requestAnimationFrame(frame);
return;
}</p><pre class='brush:php;toolbar:false;'>// 批量执行，但不超限
while (i < tasks.length && now - start < maxTime) {
tasks[i]();
i++;
now = performance.now();
}
if (i < tasks.length) {
requestAnimationFrame(frame);
}}
requestAnimationFrame(frame); }
// 使用示例：批量更新 5000 个 DOM 节点（避免强制同步布局）
const updates = Array.from({ length: 5000 }, (_, idx) => () => {
const el = document.getElementById(item-${idx});
if (el) el.style.transform = translateX(${(idx * 2) % 300}px);
});
scheduleInFrames(updates, { batchSize: 30, maxTime: 3 });
配合动画的注意事项
当 rAF 用于驱动视觉动画（如滚动、拖拽、过渡）时，拆分逻辑要和渲染职责分离：
- 纯计算（数据处理、状态推导）可以拆分，放在 rAF 中逐步做
- 但最终的样式/属性写入（write）建议集中在单次 rAF 尾部，且尽量只写 transform / opacity —— 这些属性不触发重排重绘，性能最高
- 避免在同一次 rAF 中先读（如 getBoundingClientRect）再写多个元素——这会触发频繁的 layout 强制同步
- 如果必须读写混合，把所有读操作提前集中做（read phase），所有写操作放最后（write phase），减少 layout thrashing
