requestIdleCallback 的 timeout 是硬性截止时间而非等待上限，超时后浏览器会强制执行回调；需优先检查 didTimeout，超时时应执行最小必要逻辑，推荐 timeout 设为 100–500ms。
requestIdleCallback 的 timeout 参数是防止任务被无限推迟的关键机制——它不是“最多等多久”，而是“最晚必须在什么时候执行”，哪怕浏览器一直忙，也会强制触发回调。
timeout 的真实含义：硬性截止时间，不是等待上限
很多人误以为 timeout: 1000 表示“最多等 1 秒”，其实它表示：“不管有没有空闲时间，到当前时间 + 1000ms 时，必须执行这个回调”。如果浏览器主线程一直繁忙（比如持续动画、长任务、频繁渲染），idle callback 可能迟迟不被调用，但一旦到达 timeout 截止时刻，浏览器会**强行中断当前任务（或插入微任务时机）并执行你的回调**，此时传入的 deadline 对象中 timeRemaining() 可能返回 0，didTimeout 为 true。
正确使用 timeout 防止无限延期的写法
- 始终检查
deadline.didTimeout，它才是判断是否被强制触发的唯一依据 - 当
didTimeout === true时，应放弃“只做轻量工作”的假设，转为执行最小必要逻辑（如切片处理、保存进度、降级执行），避免阻塞 - 不要依赖
timeRemaining() > 0做唯一判断；timeout 触发后它可能返回 0，但仍需执行 - 推荐设置 timeout 在 100–500ms 之间：太短易频繁强制触发，太长起不到防卡死作用
一个防延期的实际例子
比如你要异步批量处理 1000 条数据，希望利用空闲时间，但绝不允许卡住用户交互：
let items = Array.from({length: 1000}, (_, i) => i);
let index = 0;
function processInIdle(deadline) {
// ✅ 关键：优先响应 timeout 强制触发
if (deadline.didTimeout || deadline.timeRemaining() > 0) {
// 每次最多处理 20 条，或直到没时间/没数据
while (index < items.length && (deadline.timeRemaining() > 0 || deadline.didTimeout)) {
doSomeWork(items[index]);
index++;
}
}
// ✅ 如果还有剩余，继续调度（注意：仅在有剩余时再调）
if (index < items.length) {
requestIdleCallback(processInIdle, { timeout: 300 });
} else {
console.log('全部完成');
}
}
requestIdleCallback(processInIdle, { timeout: 300 });
注意事项和常见坑
- timeout 不是 Promise，不会自动重试；你必须自己判断是否继续调度
- 若回调执行时间过长（比如超过 50ms），可能影响帧率；务必在循环中反复检查
timeRemaining()或didTimeout - 部分旧版 Safari 不支持 timeout，需 feature detect 并降级为
setTimeout回退 - 不要在 timeout 触发后仍尝试做大量计算——它本就说明主线程已严重过载，此时应保响应性优先
