前端怎样把非关键任务放到空闲时间

埋点整理、搜索索引预计算、低优先级缓存预热都不应该和点击、滚动、动画争抢同一段主线程时间。requestIdleCallback()适合把这类可拆分工作放进浏览器判断出的空闲窗口，但它不是“保证马上执行”的后台线程：没有空闲时间时，回调可能延后很久；没有设置超时时间的任务甚至可能一直等下去。

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

实用方案是“空闲时小步处理，超时后走降级”：用 deadline.timeRemaining() 尊重当前窗口，用 timeout 保证有时限的工作不会无限等待，再把真正的 DOM 提交交给 requestAnimationFrame()。

先判断哪些任务值得放进空闲队列

适合进入空闲队列的任务有三个共同点：不影响当前交互、可以拆成多个独立单元、每个单元的耗时相对可预测。例如整理待发送的统计事件、解析下一屏的索引、计算本地搜索候选。首屏布局、按钮点击反馈、输入法相关处理和动画帧更新不应直接塞进这里。

可以先把任务放入队列，再只安排一个回调，避免每加入一个任务就创建一组竞争的 idle callback：

const pending = [];
let idleHandle = 0;

function enqueue(task) {
  // 只收纳可以拆分且不阻塞当前交互的低优先级任务。
  pending.push(task);
  if (!idleHandle) scheduleIdleWork();
}

function scheduleIdleWork() {
  // 特性检测后再使用，兼容分支会延迟执行而不是假装有空闲时间。
  if ('requestIdleCallback' in window) {
    idleHandle = requestIdleCallback(runIdleWork, { timeout: 1500 });
  } else {
    idleHandle = window.setTimeout(() => runIdleWork(), 100);
  }
}

用 deadline 控制每一轮处理量

回调收到的 IdleDeadline 有两个关键成员。timeRemaining()返回浏览器估计还剩多少毫秒，适合决定是否继续取下一个任务；didTimeout表示本次调用是因为超时触发。空闲窗口很短时，不要试图一次清空队列，处理一个小单元后回到事件循环。

下面的循环把“有时间”与“已到时限”分开表达。任务处理函数应保持短小，若单个任务本身就很重，仍需在任务内部继续拆分。

function runIdleWork(deadline) {
  idleHandle = 0;
  const forced = deadline?.didTimeout === true;

  // 超时时只做受控的最小工作，正常空闲时遵守剩余时间。
  while (pending.length > 0 && (forced || deadline.timeRemaining() > 2)) {
    const task = pending.shift();
    task();
    if (forced && pending.length > 0) break;
  }

  // 队列未清空就重新排队，避免一次回调长时间占用主线程。
  if (pending.length > 0) scheduleIdleWork();
}

这里的 2 不是浏览器规定的安全值，而是给回调收尾留下的工程余量。实际项目应根据任务单元耗时和交互指标调整，不能把它当成“每台设备都能执行 2 毫秒”的承诺。

用 timeout 兜底，并设计真正的降级结果

用户持续滚动、动画持续播放或设备长期繁忙时，单纯依赖空闲窗口会让任务饥饿。timeout到期后浏览器会安排回调，即使这可能带来一定的交互压力；此时 timeRemaining()通常接近 0，不能继续按普通空闲逻辑猛跑。

因此超时分支应该有明确结果：统计事件可以先合并后发送，索引可以只生成首批，预计算可以记录“待下次打开继续”，而不是无条件清空全部任务。若任务必须完成，按批次限制工作量；若任务可丢弃，直接丢弃低价值尾部并记录原因。

不支持该 API 时也不要直接同步执行全部工作。可以用 setTimeout 做粗粒度延迟，但它不知道浏览器当前是否正在处理输入；如果任务很重要，还要保留用户可见的“稍后处理”状态。

让 DOM 更新回到 requestAnimationFrame

空闲回调更适合读取队列、计算数据和准备 DocumentFragment。大块 DOM 修改会触发样式、布局和绘制，耗时不可预测；把它直接放在 idle callback 里，可能刚获得空闲时间就把下一次交互推迟了。

一个稳妥的边界是：空闲阶段只准备结果，使用 requestAnimationFrame()在下一帧提交少量 DOM 变化。如果使用虚拟 DOM，也应让框架或渲染调度层负责提交，而不是在空闲回调中循环追加节点。

let fragment = null;
let frameHandle = 0;

function prepareRows(deadline) {
  // 空闲阶段只计算和组装片段，不直接读取布局或批量改 DOM。
  while (deadline.timeRemaining() > 2 && sourceRows.length) {
    const row = buildRow(sourceRows.shift());
    (fragment ||= document.createDocumentFragment()).append(row);
  }
  if (fragment && !frameHandle) {
    frameHandle = requestAnimationFrame(commitRows);
  }
  if (sourceRows.length) requestIdleCallback(prepareRows, { timeout: 1000 });
}

function commitRows() {
  frameHandle = 0;
  // 动画帧内提交有限数量的 DOM 变更，避免把空闲阶段变成长任务。
  if (fragment) list.append(fragment);
  fragment = null;
}

上线前检查四个边界

• 任务是否真的可延迟、可拆分，是否会影响当前输入或动画。
• 每个任务单元是否有上限；不能用一个不可拆分的大函数消耗整个 deadline。
• 设置 timeout 后，didTimeout分支是合并、缩小批次、延期，还是放弃尾部，是否可观测。
• 兼容分支是否仍然分批执行；组件卸载时是否调用 cancelIdleCallback() 或清理 setTimeout。

判断这套方案是否有效，不是看 idle callback 调用了几次，而是看输入延迟、长任务和队列滞留是否改善。对关键任务保留正常调度路径，对非关键任务接受延期，才能让“放到空闲时间”成为可控的工程策略。

常见问题

没有设置 timeout 会怎样？

在页面持续繁忙时，回调可能等待很久。因此只有不在乎完成时限的低价值任务才适合省略 timeout。

可以在 requestIdleCallback 里直接改 DOM 吗？

不建议批量修改。先准备数据或片段，再在 requestAnimationFrame 中提交少量变更，更容易控制布局和交互成本。