requestIdleCallback 是浏览器提供的空闲时间回调机制，仅在主线程无高优先级任务时由浏览器自主调度执行，适合非关键任务且需配合 timeout 和分片处理。
requestIdleCallback 是什么，它真能“空闲时执行”？
requestIdleCallback 不是定时器，也不是异步队列调度器。它只是告诉浏览器：“如果接下来有空闲时间，请调用这个函数”。所谓“空闲”，指主线程没有高优先级任务（如渲染、用户输入响应、setTimeout 回调）在排队或执行。浏览器决定是否调用、何时调用、是否拆分执行，开发者无法强制触发。
它适合做那些「做了更好，不做也不影响核心功能」的事，比如：
- 非关键路径的日志上报（
analytics.track） - 低优先级的 DOM 清理（
cleanupStaleNodes） - 渐进式数据预加载（
prefetchNextPageData）
为什么不用 setTimeout(0) 或 Promise.then？
这两者都会把任务塞进微任务或宏任务队列，在下一帧前就可能被执行，甚至挤占渲染时间。而 requestIdleCallback 的回调只会在帧末尾、浏览器确认有剩余时间时才运行，天然避开了 RAF 和渲染阶段。
对比关键差异：
立即学习“Java免费学习笔记（深入）”；
-
setTimeout(fn, 0)：立刻入宏任务队列，可能打断当前帧渲染 -
Promise.resolve().then(fn)：入微任务队列，紧接在当前同步代码后执行，仍可能阻塞绘制 -
requestIdleCallback(fn)：由浏览器判断时机，保证不抢帧，且支持超时控制（{ timeout: 2000 }）
实际使用时必须处理的三个现实问题
很多人写了 requestIdleCallback 却没效果，往往卡在这三点：
- 浏览器兼容性：Safari 直到 15.4 才支持，旧版需用
setTimeout+performance.now()模拟空闲检测 - 回调可能永不执行：页面持续高频交互（如滚动、动画），
requestIdleCallback就一直等不到空闲 —— 必须配合timeout选项兜底 - 不能假设单次调用能做完所有事：回调传入的
deadline对象有timeRemaining()和didTimeout，必须主动检查并分片执行
function doWork(deadline) {
while (deadline.timeRemaining() > 0 && tasks.length > 0) {
processNextTask();
}
if (tasks.length > 0) {
requestIdleCallback(doWork, { timeout: 1000 });
}
}
requestIdleCallback(doWork, { timeout: 1000 });
它提升用户体验的关键不在“快”，而在“不卡”
真正改善体验的不是让某个非关键操作更快完成，而是确保它从不拖慢按钮点击反馈、列表滚动帧率或首屏渲染。比如一个搜索页在用户打字间隙悄悄预取下一页结果，但一旦用户开始滚动，它就暂停；等用户停下来，再继续。这种“感知不到的后台工作”，才是 requestIdleCallback 的价值所在。
容易被忽略的是：它无法替代合理的懒加载、虚拟滚动或 Web Worker。如果你发现需要大量使用它来“补性能债”，说明更该回退一步，检查是否本该用更底层的优化手段。
