requestIdleCallback 怎样为非关键任务安排空闲执行

结论先说：requestIdleCallback() 适合统计上报准备、预渲染和低优先级计算这类“不影响当前交互”的工作。把任务放进队列后，在回调收到的 IdleDeadline 还有余量时处理一小块；余量不足就重新排队，并为确实需要完成的任务设置 timeout。

官方地址：https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback

实用配方可以记成三句话：非关键任务才进入空闲队列；每次处理都看 deadline.timeRemaining()；浏览器不支持时，用同一任务队列配合 setTimeout 降级。

问题：为什么不能把非关键工作直接放进 setTimeout

setTimeout(fn, 0) 只能把回调放入事件循环，并不会告诉浏览器“这件事可以等到空闲时再做”。如果回调里一次处理大量数据，仍可能和输入、动画或渲染争用主线程。requestIdleCallback() 的目的，是让浏览器在认为主线程暂时空闲时调用回调，并传入一个截止信息。

它并不保证立刻执行。页面持续繁忙时，空闲期可能很短，甚至迟迟没有合适的空闲时间。因此，低优先级任务应当可拆分、可暂停；如果业务必须在某个时间范围内开始处理，就给调度调用加上正数 timeout。

最小配方：根据 deadline 分块处理

下面的例子把数组中的工作拆成小块。关键不在于猜一个固定毫秒数，而是每次循环都询问 timeRemaining()。当任务仍有剩余并且本轮时间充足时继续；否则保存队列状态，等待下一个空闲回调。

const pending = Array.from({ length: 30 }, (_, index) => index);
let idleId = 0;

function consume(deadline) {
  // 只在本轮空闲时间还有余量时处理，避免一次占满主线程。
  while (pending.length > 0 && (deadline.timeRemaining() > 4 || deadline.didTimeout)) {
    const item = pending.shift();
    // 这里替换成统计整理、预渲染等低优先级工作。
    console.log("处理任务", item);
  }

  if (pending.length > 0) {
    // 还有任务就排到下一次空闲期，不要在当前回调里硬撑。
    idleId = window.requestIdleCallback(consume, { timeout: 1000 });
  }
}

// timeout 给长期繁忙的页面提供一个可接受的开始时间上限。
idleId = window.requestIdleCallback(consume, { timeout: 1000 });

deadline.didTimeout 为真时，说明本次回调是因为超时而被安排，代码可以完成一个小批次，但仍应避免无界循环。保存 idleId 是为了在页面销毁、组件卸载或用户取消操作时调用 cancelIdleCallback(idleId)。

变体：把必须完成与可延迟工作分开

空闲调度不是“所有异步工作的默认入口”。用户点击后的即时反馈、动画帧内必须完成的更新、支付提交等关键工作，应走自己的时序。适合进入空闲队列的，通常是可以晚一点做、可以拆成小块、失败后能重试的工作。

如果队列属于可取消的页面任务，取消动作要和任务状态放在一起管理：

let idleHandle = 0;
let stopped = false;

function stopBackgroundWork() {
  // 先设置业务状态，避免已经进入回调的任务继续添加新任务。
  stopped = true;
  if (idleHandle !== 0) {
    // 只取消尚未开始的空闲回调，已执行的代码仍需自己检查状态。
    window.cancelIdleCallback(idleHandle);
    idleHandle = 0;
  }
}

注意，取消调度句柄不能撤销已经完成的副作用；真正可控的边界仍是回调内部的状态检查和小批次设计。

兼容坑：不支持时如何降级

这个 API 在部分常用浏览器中并非普遍可用，不能只写新 API 就结束。降级时仍然复用同一个任务函数：支持时读取真实的 IdleDeadline，不支持时用一个带有 timeRemaining() 和 didTimeout 的最小对象，避免业务逻辑分叉。

function runIdleQueue(work) {
  // 优先使用浏览器空闲调度；不支持时退回普通定时任务。
  if ("requestIdleCallback" in window) {
    return window.requestIdleCallback(work, { timeout: 1000 });
  }

  return window.setTimeout(() => {
    // 降级对象只提供业务代码需要的两个字段，时间预算由应用约束。
    const fallbackDeadline = {
      didTimeout: true,
      timeRemaining: () => 8
    };
    work(fallbackDeadline);
  }, 0);
}

runIdleQueue((deadline) => {
  // 统一消费入口，具体任务仍必须保持可拆分和可重入。
  if (deadline.timeRemaining() > 0 || deadline.didTimeout) {
    console.log("处理一个非关键任务");
  }
});

降级不是性能等价替代：setTimeout 不知道浏览器下一帧还剩多少空间，所以每次工作量要更保守。若页面隐藏、网络状态或业务时限会影响结果，还要在任务层补充取消、重试和状态持久化。

常见问题

设置了 timeout 后，回调还会等到空闲吗？

正常情况下仍优先在空闲期调用；如果等待超过指定毫秒数，浏览器会把回调排入事件循环。因此 timeout 是开始处理的时间边界，不是“保证一次处理完全部任务”的承诺。

为什么回调里还要再次 requestIdleCallback？

因为一次空闲期的时间预算有限。重新排队能让浏览器重新评估下一段空闲时间，配合队列游标或批次索引，就能把长工作拆开而不阻塞当前交互。