requestIdleCallback适合在浏览器空闲时发日志，用于非关键、可延迟的日志补报，如页面加载后埋点、错误兜底采集、用户行为聚合回传，需搭配timeout降级至setTimeout或sendBeacon以保障必达。
requestIdleCallback 什么时候适合发日志
它不是用来替代 fetch 或 sendBeacon 的通用上报方案，而是专为「不抢主线程、不影响用户交互」的日志补报设计的。比如页面加载后埋点延迟上报、错误兜底采集、用户行为聚合后的轻量级回传——这些场景下，你希望等浏览器真正空闲了再发，而不是一上来就挤占渲染资源。
常见错误现象：requestIdleCallback 回调没执行、日志始终不上报、或只在 DevTools 打开时才触发。根本原因是它受浏览器调度策略限制：后台标签页、低电量模式、或任务队列长期繁忙时，回调可能被无限推迟甚至丢弃。
- 必须搭配超时机制（
timeout参数），否则可能永远等不到空闲 - 不能依赖它保证必达，关键日志仍需用
sendBeacon或立即fetch - Chrome 与 Safari 实现差异大：Safari 直到 iOS 16.4 / macOS 13.3 才支持，且无
timeout支持
怎么写一个带 fallback 的日志上报封装
核心是三层兜底：先尝试 requestIdleCallback，超时则降级为 setTimeout，最后若连定时器都不可靠（如页面即将卸载），改用 sendBeacon。
function reportLog(logData) {
const payload = JSON.stringify(logData);
const idleTask = (deadline) => {
if (deadline.timeRemaining() > 0) {
navigator.sendBeacon('/log', payload);
} else {
// 空闲时间不够，延后重试（但最多试一次）
setTimeout(() => navigator.sendBeacon('/log', payload), 0);
}
};
// timeout 设为 2000ms 是经验值：既避免久等，又留出合理空闲窗口
if ('requestIdleCallback' in window) {
requestIdleCallback(idleTask, { timeout: 2000 });
} else {
// 降级：直接 sendBeacon 或 fetch
navigator.sendBeacon?.('/log', payload) ||
fetch('/log', { method: 'POST', body: payload });
}
}
-
timeout值不宜小于 1000，否则在低端机上容易直接跳过空闲阶段 - 不要在
requestIdleCallback中做序列化、过滤、拼接等计算，这些应前置完成 -
sendBeacon要求 endpoint 支持接收text/plain，否则服务端需显式处理原始 body
为什么不用 setTimeout(0) 或 Promise.resolve() 替代
它们只是把任务塞进微任务或宏任务队列，仍会打断当前帧渲染或输入响应。而 requestIdleCallback 是浏览器明确暴露的「空闲期」信号，由调度器判断是否真有空余时间。
-
setTimeout(0)可能在 layout/paint 前插入，导致 FPS 下降 -
Promise.resolve().then()属于微任务，优先级高于渲染，强制同步执行风险更高 -
requestIdleCallback的timeRemaining()是唯一能感知“此刻是否真空闲”的 API
换句话说：你想“见缝插针”，就得用浏览器给的那根针，而不是自己拿牙签硬捅。
上报失败时如何避免重复触发
requestIdleCallback 不提供执行状态反馈，回调一旦发起，无法取消或重试控制。所以日志对象本身要带幂等标识，比如 id + timestamp 组合，服务端去重；前端则需避免多次注册同一日志。
- 上报前检查
performance.getEntriesByType('navigation')[0]?.type === 'reload'，跳过刷新场景的重复采集 - 对用户行为日志（如点击），加防抖：500ms 内相同事件只合并上报一次
- 利用
WeakMap缓存已提交的 log 对象引用，防止同一对象被多次传入reportLog
最易被忽略的一点：空闲回调里不做跨域请求（fetch）——它没有凭据且无法携带 cookie，而 sendBeacon 默认携带，但仅限同源。跨域上报必须提前配置 CORS 或换用图片打点。
