requestidlecallback仅在主线程空闲且距下一帧≥50ms时调度，chrome 47+、safari 15.4+支持，firefox至今不支持；需降级方案，避免误判必执行，须用timeout兜底并检查timeremaining()，禁dom写操作。
requestIdleCallback 什么时候真正可用
它不是随时都能用的——只在浏览器主线程空闲、且距离下一帧渲染还有至少 50ms 时才可能被调度。Chrome 从 47 版开始支持，但 Safari 直到 15.4 才完整支持（iOS 15.4+），Firefox 仍不支持（截至 2024 年中）。如果你的应用必须兼容 Firefox 或旧版 Safari，requestIdleCallback 不能作为唯一路径，得有降级方案。
常见误判是以为“只要调用了就一定会执行”，其实它可能被系统直接丢弃：比如用户切到其他 tab、页面进入后台、或主线程突然被大量任务占满，requestIdleCallback 的回调可能永远不触发。
- 用
timeout参数强制兜底（推荐设为 2000–3000ms） - 始终检查回调参数
deadline.timeRemaining()> 0，再决定是否继续执行 - 不要在回调里做 DOM 写操作（如
el.innerHTML = ...），否则可能触发强制同步重排
如何安全地分片处理长任务
典型场景是遍历上千条数据做格式转换、批量上报或本地索引构建。直接 for 循环会卡住主线程；用 requestIdleCallback 分片，关键是每次只干“够小”的事，并主动让出控制权。
下面这个模式能避免超时和饥饿：
function processInIdle(items, index = 0) {
const chunkSize = 20;
return function(deadline) {
while (index 1) {
// 做单条处理（纯计算，无 DOM 写）
transformItem(items[index]);
index++;
}
if (index
- 每次只处理约 20 条（根据实际单条耗时微调），确保
timeRemaining()不被耗尽 - 不依赖
deadline.didTimeout自动重入——它只在 timeout 触发时为 true，不可靠 - 把状态（如
index）闭包传入，而不是存在全局变量，避免并发或多次调用冲突
哪些逻辑适合放进去，哪些绝对不行
适合的：日志聚合上报、非关键缓存更新、离线数据预处理、分析埋点拼装、Web Worker 初始化前的参数准备。
绝对不行的：
- 任何影响当前帧视觉输出的操作：
el.style.width、el.classList.add、scrollTo - 依赖实时 DOM 状态的判断（比如“按钮是否还在页面上”），因为回调执行时 DOM 可能已被移除
- 需要强顺序保证的副作用（如连续发两个
fetch，第二个依赖第一个响应），idle 回调不保证执行顺序或频率 - 用户交互直接触发的反馈（比如点击后要立刻变色），这类必须走同步或
Promise.then+queueMicrotask
降级到 queueMicrotask 或 setTimeout 的实操要点
当 requestIdleCallback 不可用，又不想退化成阻塞式执行，优先选 queueMicrotask（Chrome 69+/Firefox 71+/Safari 15.4+），它比 setTimeout(..., 0) 更及时，且不会抢占渲染时机。
一个稳妥的 fallback 写法：
const runIdle = window.requestIdleCallback ||
(window.queueMicrotask ?
(cb, opts) => queueMicrotask(() => cb({ timeRemaining: () => 10, didTimeout: false })) :
(cb, opts) => setTimeout(cb, opts?.timeout || 1));
runIdle(() => {
// 你的逻辑
});
-
queueMicrotask降级时，手动模拟一个简易deadline对象，避免原逻辑报错 - 不用
Promise.then降级，因为它的调度优先级高于queueMicrotask，可能挤占 microtask 队列导致响应延迟 - 如果目标环境明确不支持
queueMicrotask（如 IE 或 Android 4.4 WebView），再退到setTimeout，并把 timeout 设为 1ms 而非 0，减少调度抖动
