requestIdleCallback 适合非关键、可降级的埋点，如停留时长估算；但不保证必达，需搭配 timeout 兜底、sendBeacon 发送、localStorage 备份及降级策略。
requestIdleCallback 适合埋点吗？先看它能不能扛住真实场景
能，但有明显限制：它只在浏览器空闲时触发，且可能被系统直接丢弃（比如页面切到后台或用户快速滚动）。埋点如果要求「必达」或「强时效」，requestIdleCallback 不该是唯一通道——它更适合非关键、可降级的统计，比如页面停留时长估算、元素可视区域统计、非核心行为采样。
常见错误现象：requestIdleCallback 注册后完全不执行，或只执行一次就消失。原因通常是：页面持续高负载（如动画、大量 DOM 更新）、用户切换标签页导致空闲时间被取消、或回调里抛了未捕获错误导致后续调用静默终止。
- 必须用
timeout参数兜底，否则低性能设备或复杂页面下可能永远等不到空闲 - 不要在回调里做 DOM 写操作（如
element.style.color = 'red'），会强制触发重排，破坏空闲前提 - 每次调用需检查
deadline.timeRemaining() > 0，不能假设一定有足够时间执行完全部逻辑
怎么写一个带超时和重试的埋点调度器
核心是把埋点任务队列化，并利用 requestIdleCallback 的「尽力而为」特性 + setTimeout 的确定性兜底。不依赖单次调用，而是让任务可拆分、可重入、可降级。
示例逻辑：
let pendingBeacon = [];
function scheduleBeacon(data) {
pendingBeacon.push(data);
requestIdleCallback(flushBeacon, { timeout: 2000 });
}
function flushBeacon(deadline) {
while (pendingBeacon.length && deadline.timeRemaining() > 5) {
const item = pendingBeacon.shift();
// 这里只做轻量序列化，不发网络请求
navigator.sendBeacon('/log', JSON.stringify(item));
}
if (pendingBeacon.length > 0) {
// 剩余任务，2秒后强制再试一次（避免卡死）
setTimeout(() => requestIdleCallback(flushBeacon, { timeout: 2000 }), 2000);
}
}
-
navigator.sendBeacon是关键：它不阻塞页面卸载，且比fetch更适合埋点场景 - 不要在
flushBeacon中做复杂计算或等待 Promise，它必须是同步、短时、无副作用的 - 如果业务要求更高可靠性，建议 fallback 到
localStorage缓存 + 页面 unload 时批量发送
为什么不能直接在 requestIdleCallback 里调 fetch 或 XMLHttpRequest
因为 requestIdleCallback 的执行时机不可控，而 fetch 是异步的，一旦回调结束、浏览器进入下一帧，Promise 回调可能被推迟到渲染之后甚至被节流。更严重的是：若用户关闭标签页，未 resolve 的 fetch 请求大概率被浏览器直接中止，日志丢失。
-
fetch不保证在页面生命周期内完成，sendBeacon才是专为此设计的 API - 即使加了
.catch，也捕获不到被浏览器主动终止的请求（不会抛错，只是静默失败） - 某些旧版 Safari 对
requestIdleCallback支持不稳定，fetch在空闲回调中还可能触发 CORS 预检失败（因 referrer 或 origin 上下文异常）
兼容性与降级策略必须手动处理
requestIdleCallback 在 Safari 中长期不支持（iOS 16.4+ / macOS 13.3+ 才开始实验性启用），且 Chrome 也会在后台标签页中禁用它。不加降级等于在部分用户群中完全失效。
最简降级方式：
const idleCallback = window.requestIdleCallback ||
((cb) => setTimeout(() => cb({ timeRemaining: () => 1 }), 1));
- 这个 fallback 不是“模拟空闲”，而是退化为
setTimeout，确保逻辑至少能跑起来 - 不要用
setInterval轮询空闲状态——它本身就会制造 CPU 占用，违背初衷 - 如果项目已用 React，注意
useEffect或useLayoutEffect的清理时机可能和requestIdleCallback冲突，需用AbortController显式控制回调生命周期
真正难的不是写对那几行代码，而是判断哪些埋点值得放进空闲队列、哪些必须立刻发、哪些可以合并压缩——这需要结合业务漏斗和数据 SLA 来权衡，而不是交给 API 自动决定。
