如何使用 requestIdleCallback 在浏览器渲染间隙分批次处理非核心的后台数据计算任务
requestIdleCallback在浏览器主线程空闲且无更高优先级任务时执行，非定时器，不保证每帧调用；若主线程持续繁忙（如滚动、输入），可能被推迟甚至超时强制执行。
requestIdleCallback 什么时候会真正执行
它只在浏览器主线程空闲、且没有更高优先级任务（比如样式计算、布局、绘制、用户输入响应）时才触发，不是定时器，也不保证每帧都调用。如果你刚调用 requestIdleCallback 就立刻开始重排版或触发 getBoundingClientRect()，那回调可能被无限推迟，甚至被丢弃（超时后强制执行但不带 didTimeout 标志）。
常见误判是以为“只要页面没卡就一定能跑”，其实滚动中、input 输入频繁、或刚提交表单后触发大量 DOM 更新，都会让空闲时间消失。建议用 performance.now() 打点验证实际触发时机，而不是依赖开发工具的帧率面板。
如何安全地分批次处理长耗时计算
核心是别把整个数组一口气遍历完，而是每次只处理一部分，并在下次空闲时继续。关键不是“切多少份”，而是“每次处理多久”——应以剩余空闲时间为依据，而非固定条数。
- 始终检查
deadline.timeRemaining() > 0，且建议留出至少 1ms 缓冲（如deadline.timeRemaining() > 1），避免压线导致下一帧掉帧 - 不要在回调里直接递归调用
requestIdleCallback；改用循环 + 条件判断，防止调用栈堆积或意外中断后无法恢复 - 记录已处理索引（如
let processed = 0），而不是每次从头 slice，避免重复计算或状态丢失 - 若任务中途被中断（
deadline.didTimeout === true），说明已超时，应立即执行剩余部分（或至少推进到下一个合理断点），否则逻辑可能卡死
示例片段：
let items = Array.from({ length: 10000 }, (_, i) => i);let processed = 0;function processBatch(deadline) { while (processed < items.length && deadline.timeRemaining() > 1) { // 这里放你的计算逻辑，比如 transform 或 aggregate const item = items[processed]; doHeavyWork(item); processed++; } if (processed < items.length) { requestIdleCallback(processBatch, { timeout: 2000 }); }}requestIdleCallback(processBatch, { timeout: 2000 });
timeout 参数不是保底执行，而是“最晚触发时间”
timeout 不代表“2秒后一定执行”，而是告诉浏览器：“如果到这时还没空闲过，那就强行给一次机会”。但它仍受主线程阻塞影响——如果主线程被一个 3 秒的同步脚本锁死，那即使设了 timeout: 2000，回调也要等到脚本执行完才可能运行。
更隐蔽的问题是：超时触发的回调，deadline.didTimeout 为 true，但 deadline.timeRemaining() 可能返回 0 或极小值（如 0.1ms），此时若仍按常规逻辑判断 > 1，就会跳过所有工作，造成任务停滞。
- 必须显式处理
didTimeout分支：一旦为true，应忽略timeRemaining()，直接处理至少一批（哪怕只做 1 次）再决定是否继续 - 不要把
timeout设得过小（如 100ms），否则频繁超时会增加调度开销，反而拖慢整体进度 - 生产环境建议搭配
console.warn记录超时次数，用于判断是否任务粒度太粗或主线程长期过载
替代方案与兼容性兜底怎么选
requestIdleCallback 在 Safari 中长期不支持（截至 Safari 17.4 仍无），且 Chrome/Firefox 也仅在主线程可用（Web Worker 里不可用）。不能当作调度基座来依赖。
- 优先检测是否存在：
if ('requestIdleCallback' in window)，不存在则降级为setTimeout(..., 0)或queueMicrotask，但要注意后者会在下一个 microtask 阶段执行，可能挤占 Promise 回调资源 - 对精度要求不高、且任务可中断的场景，
setTimeout(fn, 0)+ 自行控制批次，比强行 polyfill 更可控 - 若需跨浏览器稳定调度，推荐用 idle-until-urgent 这类轻量封装，它内部做了特征检测和 fallback，不试图模拟空闲逻辑，只做“尽力而为”的协调
- 注意：Node.js 环境完全不支持，服务端渲染（SSR）中调用会报错，务必包裹运行时检查
真正难的不是写几行 requestIdleCallback，而是判断哪些计算真的“非核心”、能否被中断、中间状态要不要持久化——这些没法靠 API 解决，得看业务逻辑本身是否具备可分割性。
