必须用timeout参数兜底，否则低性能设备或复杂页面下可能永远等不到空闲；回调中需通过deadline.didTimeout区分触发原因，并据此调整执行策略。

requestIdleCallback 为什么需要 timeout 参数

不加 timeout 的 requestIdleCallback 可能永远不触发——比如页面持续有高优先级任务（滚动、动画、频繁 setTimeout），浏览器判定“没有空闲”，回调就被搁置。这不是 bug，是设计使然：它只承诺“空闲时调用”，不承诺“一定会调用”。加 timeout 是唯一能打破无限等待的手段。

正确传入 timeout 的写法和常见错误

timeout 必须作为第二个参数以对象形式传入，不能直接当第三个参数；且单位是毫秒，不是帧数或秒。漏掉大括号、写错键名、超时值过小（如 1）都会导致失效或误触发。

• ✅ 正确：requestIdleCallback(callback, { timeout: 3000 })
• ❌ 错误：requestIdleCallback(callback, 3000)（被忽略）
• ❌ 错误：requestIdleCallback(callback, { Timeout: 3000 })（大小写敏感，无效）
• ❌ 错误：requestIdleCallback(callback, { timeout: 1 })（可能在空闲前就超时，失去空闲调度意义）

如何在回调里区分是空闲触发还是超时触发

requestIdleCallback 的回调接收一个 deadline 对象，它有 timeRemaining() 和 didTimeout 两个关键属性。didTimeout 为 true 表示本次是因超时而执行，此时不应假设还有剩余时间可安全执行长任务。

requestIdleCallback((deadline) => {
  if (deadline.didTimeout) {
    // 超时触发：应尽快执行，不依赖 timeRemaining()
    runUrgentTask();
  } else {
    // 真正空闲触发：可分片执行，检查 timeRemaining() > 0
    while (deadline.timeRemaining() > 0 && tasks.length > 0) {
      doOneTask();
    }
    if (tasks.length > 0) {
      requestIdleCallback(arguments.callee, { timeout: 3000 });
    }
  }
}, { timeout: 3000 });

timeout 值设多少才合理

没有通用最优值，取决于任务紧急程度和用户预期。3000ms（3 秒）是较稳妥的底线：既避免用户明显感知卡顿，又给空闲机会留出余量。若任务影响 UI 响应（如输入联想），可压到 1000ms；若只是日志上报，5000ms 也无妨。但要注意：timeout 不是“最多等这么久”，而是“最晚在这个时间点强制触发”——如果之前已进入空闲并执行了回调，timeout 就不会生效。

真正容易被忽略的是：超时触发后，deadline.timeRemaining() 返回 0，且不能再用它做分片判断。这时候必须切换成同步执行逻辑，否则任务会静默丢弃。