如何利用 requestIdleCallback 分片处理海量数据的增量计算

分片计算需每帧控制在2ms内并主动退出，禁用DOM操作，兼容降级需模拟timeRemaining和超时逻辑，中断时须保存offset与中间状态。

能用，但必须拆得够细、退出够快、不碰 DOM，否则照样卡死。

为什么直接 for 循环处理 10 万条数据会卡住页面

主线程被独占，浏览器没机会响应滚动、点击或渲染下一帧。哪怕只是 JSON.parse 或 Array.map 一串长数组，只要单次执行超过 16ms，用户就会感知到卡顿。

常见错误现象：

• 调用 requestIdleCallback 后，任务只执行一次就停了，数据没处理完
• 在回调里直接 document.createElement 或修改 innerHTML，触发重排重绘，抵消空闲收益
• 没检查 deadline.timeRemaining() > 0 就硬塞循环，导致单次耗时爆表

分片计算的核心写法：每帧只干“几毫秒”的活

关键不是“分多少批”，而是“每批干多久”——必须在 deadline.timeRemaining() 耗尽前主动退出。

实操建议：

• 用 while (deadline.timeRemaining() > 2 && i 控制循环，留至少 2ms 缓冲
• 每次只处理 50–200 条（具体看单条耗时，可先测 10 条平均耗时再推算）
• 把纯计算逻辑（如格式化、校验、聚合）和 DOM 渲染完全分离：先用 requestIdleCallback 算完结果，再用 requestAnimationFrame 批量上屏
• 若 deadline.didTimeout === true，说明已超时，此时应尽快收尾，避免打断用户操作

示例节选：

function processBatch(data, start, batchSize, deadline) {  let i = start;  while (i < Math.min(start + batchSize, data.length) && deadline.timeRemaining() > 2) {    // 这里只做纯数据操作，不碰 DOM    result.push(transform(data[i]));    i++;  }  if (i < data.length) {    requestIdleCallback((nextDeadline) =>       processBatch(data, i, batchSize, nextDeadline)    );  }}

兼容性 fallback 必须覆盖 timeout 行为

旧版 Safari 或 Firefox 不支持 requestIdleCallback，降级用 setTimeout 时，options.timeout 会丢失——这意味着你写的超时逻辑在降级后根本不会触发。

实操建议：

• 不要只依赖 setTimeout(() => {}, 0)，要模拟 timeout 参数：用 performance.now() 记录起始时间，在每次迭代前判断是否超时
• 降级函数里也需保留 timeRemaining() 的语义，比如返回 Math.max(0, 16 - (performance.now() - start))
• 检测到 didTimeout 为 true 时，后续批次应改用 requestAnimationFrame 或立即同步执行，防止无限延迟

容易被忽略的边界点：缓存与中断恢复

用户中途滚动、切换 Tab 或触发高优事件时，requestIdleCallback 可能被系统暂停甚至丢弃。如果计算过程不可逆（比如文件 hash 分片），就得自己维护 offset 和中间状态。

真正难的不是“怎么分片”，而是“断点在哪、状态怎么存、失败后怎么续”。比如：

• 用闭包或 Ref（Vue）/ useState（React）保存当前处理到第几项
• 对中间结果做轻量序列化（如 JSON.stringify({ offset, partialResult })），避免全量重算
• 监听 pagehide 或 visibilitychange，主动取消未完成的 requestIdleCallback 并持久化进度

这些细节不处理，看似“用了 API”，实际线上仍会因意外中断导致数据错乱或重复计算。