JavaScript requestIdleCallback 如何安排后台任务：空闲回调与超时兜底

页面首屏已经出来了，但搜索索引、埋点整理和离线缓存仍然会抢主线程。把这些工作直接塞进 setTimeout(fn, 0)，只能说明它晚一点排队，不能说明它会避开用户输入。更合适的做法是用 requestIdleCallback 把任务切到浏览器空闲窗口，并用 timeout 给一直没有空闲时间的页面留一条可验收的兜底路径。

小任务先看 IdleDeadline.timeRemaining()，不够就让出主线程；只有超过 timeout 后由 didTimeout 触发的回调，才应该放宽“必须空闲”的条件。

requestIdleCallback 解决的是哪一种慢

假设列表页需要把 600 条记录整理成搜索索引。这个工作可以晚几百毫秒甚至几秒完成，却不应该挡住用户滚动。requestIdleCallback 允许浏览器在一帧的绘制和输入处理之后，尝试调用回调；回调参数 deadline 会告诉代码当前还剩多少估算空闲时间。

它不是后台线程，也不是把计算移出主线程。回调里的 JavaScript 仍然运行在主线程，单次处理太多数据照样会造成卡顿。因此，真正的单位不是“整批索引”，而是“在预算内处理几条”。

用 timeRemaining() 把索引工作切成小段

下面的 runChunk 只处理一个批次，并把 cursor 留在闭包里。图中只保留正文真实出现的三个节点：requestIdleCallback、runChunk、timeRemaining()。

const records = loadRecords();
let cursor = 0;

function runChunk(deadline) {
  while (cursor  1) {
    buildSearchEntry(records[cursor]);
    cursor += 1;
  }

  if (cursor 

这里的判断顺序很重要：先确认还有记录，再确认本轮时间预算大于 1 毫秒。预算不足时，cursor 不会前移，下一次回调会从同一条记录继续。不要把 while 条件改成只判断数组长度，否则一批 600 条记录可能一次性占满主线程。

timeout 到期后，为什么还要检查 didTimeout

空闲回调可能一直等不到理想窗口：用户持续输入、页面动画不断，或者主线程一直被其他任务占用。传入 timeout: 2000 后，浏览器会在超时后安排回调，此时 deadline.didTimeout 为 true，而 timeRemaining() 通常接近 0。

function runChunk(deadline) {
  const forced = deadline.didTimeout;
  const budget = forced ? 1 : deadline.timeRemaining();

  while (cursor  1) {
    buildSearchEntry(records[cursor]);
    cursor += 1;
  }

  if (cursor 

这个示例故意没有在超时分支里一次处理完全部数据。超时只表示“不能再无限等待”，不表示“现在可以长时间运行”。生产代码可以把兜底批次限制为一条或几条，然后继续排队；如果任务本身必须连续占用大量 CPU，应考虑 Web Worker。

requestIdleCallback 和 setTimeout 怎么选

能力检测可以写成下面这样。不要直接调用全局名称，否则在不支持该 API 的环境中会在进入降级逻辑前抛出 ReferenceError。

const scheduleIdle = window.requestIdleCallback
  ? (task) => window.requestIdleCallback(task, { timeout: 2000 })
  : (task) => window.setTimeout(() => task({
      didTimeout: true,
      timeRemaining: () => 1
    }), 0);

scheduleIdle(runChunk);

三个容易误判的边界

把 requestIdleCallback 当成精准定时器

它只表达“有空时做”，不承诺某个固定毫秒点执行。需要控制动画帧时看 requestAnimationFrame，需要最长等待时间时才配置 timeout。

在回调里读取过期业务状态

回调可能在用户完成一次筛选后才运行。开始批次前应检查当前列表版本或过滤条件，避免把旧结果写回新列表。

只在开发机验证，不观察输入响应

用 Chrome DevTools Performance 录制一次“连续输入 + 后台索引”，检查 Long Task 和输入事件间隔。验收目标不是回调一定很快，而是索引批次不会制造新的长任务。

相关问题

requestIdleCallback 能替代 Web Worker 吗？

不能。它仍在主线程，只适合把小工作拆到空闲时段；大计算应移到 Web Worker。

timeout 设置得越小越好吗？

不是。过小会频繁进入超时路径，过大又可能让低优先级任务长期没有结果，应按业务可接受的延迟和单批成本压测。

timeRemaining() 返回 0 时应怎么办？

保存当前游标，重新调用 requestIdleCallback，不要在同一回调里强行完成剩余数组。

把验收标准写进代码

这类调度最容易被误用成“换一个延迟函数”。可验收的实现应同时具备三点：runChunk 有明确游标，timeRemaining() 控制单次预算，didTimeout 只触发有限兜底。上线前再用 Performance 面板观察真实输入场景，确认低优先级工作确实让出了主线程。