分片计算需每帧控制在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 2) {
// 这里只做纯数据操作，不碰 DOM
result.push(transform(data[i]));
i++;
}
if (i
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”，实际线上仍会因意外中断导致数据错乱或重复计算。
