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 1) {
// 这里放你的计算逻辑，比如 transform 或 aggregate
const item = items[processed];
doHeavyWork(item);
processed++;
}
if (processed
<h3>timeout 参数不是保底执行，而是“最晚触发时间”</h3>
<p><code>timeout</code> 不代表“2秒后一定执行”，而是告诉浏览器：“如果到这时还没空闲过，那就强行给一次机会”。但它仍受主线程阻塞影响——如果主线程被一个 3 秒的同步脚本锁死，那即使设了 <code>timeout: 2000</code>，回调也要等到脚本执行完才可能运行。</p>
<p>更隐蔽的问题是：超时触发的回调，<code>deadline.didTimeout</code> 为 <code>true</code>，但 <code>deadline.timeRemaining()</code> 可能返回 0 或极小值（如 0.1ms），此时若仍按常规逻辑判断 <code>> 1</code>，就会跳过所有工作，造成任务停滞。</p>
- 必须显式处理
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 解决，得看业务逻辑本身是否具备可分割性。
