requestIdleCallback仅在浏览器主线程空闲且无高优先级任务时触发，可能被丢弃；需手动cancelIdleCallback取消、用deadline.timeRemaining()判断执行余量，并做好兼容降级。
requestIdleCallback 什么时候会真正触发
它只在浏览器主线程空闲、且没有更高优先级任务（比如渲染、用户输入响应）时才调用，不是“定时器”，也不是“延迟执行”。如果页面持续有动画、滚动、高频事件，requestIdleCallback 可能一直不执行，甚至被浏览器主动丢弃（超时后触发 timeout 选项）。
常见误判场景：
- 在
setTimeout(() => { requestIdleCallback(cb) }, 0)里包裹，以为能“确保执行”——实际只是推迟到下一个任务队列，仍受空闲条件限制 - 在 React 的
useEffect或 Vue 的mounted中直接调用，没考虑组件卸载后回调仍在排队，导致this或状态已失效 - 传入的回调函数做了同步耗时操作（如遍历大数组、JSON.parse 大字符串），违反了“空闲任务应轻量”的前提，反而拖慢后续渲染
如何安全注册并取消 requestIdleCallback
必须保存返回的 id，并在不需要时调用 cancelIdleCallback(id)。尤其在单页应用中，组件销毁、路由切换、数据重置时，不取消会导致内存泄漏或错误执行。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用变量暂存
id，例如：let idleId = requestIdleCallback(doWork) - 在清理逻辑中明确调用：
if (idleId) cancelIdleCallback(idleId) - 不要依赖
setTimeout模拟取消——requestIdleCallback不提供清除钩子，只能靠手动 cancel - 若需多次调度，每次调用都产生新
id，旧id不会自动失效，必须显式 cancel
怎么判断任务是否该继续执行（利用 deadline）
回调函数接收的 deadline 参数是关键。它不是时间戳，而是带 timeRemaining() 和 didTimeout 的对象。你应该用 deadline.timeRemaining() > 0 判断是否还有余量，而不是硬写 if (Date.now() 。
典型用法：
- 对长列表做分片处理：
while (items.length && deadline.timeRemaining() > 1) { processOne(items.pop()); } - 遇到
deadline.didTimeout === true，说明浏览器强制给了时间片但任务超时，此时应立即执行剩余工作（避免饥饿），或至少 commit 当前进度 - 不要在
timeRemaining()返回 0 后还强行循环——这会让浏览器无法及时响应下一帧
兼容性与降级方案要不要加
Chrome 47+、Firefox 55+、Safari 15.4+ 支持，Edge 基于 Chromium 后也支持。但 iOS Safari 15.2–15.3 有严重 bug：deadline.timeRemaining() 恒为 0，导致任务永不执行；Android WebView 旧版本也可能不触发。
稳妥做法：
- 始终封装一层判断：
if ('requestIdleCallback' in window) { ... } else { setTimeout(fn, 0) } - 避免把核心逻辑（如数据上报、状态保存）完全交给
requestIdleCallback，关键路径保留同步或setTimeout保底 - 不要用
Promise.resolve().then()代替——它属于微任务，优先级高于空闲任务，可能挤占真实空闲时间
真正容易被忽略的是 deadline 的语义：它不是“还剩多少毫秒”，而是“浏览器当前愿意给你多少弹性时间”，这个值动态变化、不可预测，依赖它做精确计时必然失败。
