用requestIdleCallback后台执行非紧急日志压缩上报保证前台丝滑

先说结论：requestIdleCallback 确实可以用于日志压缩上报，但前提是必须填好几个坑——日志必须已经存入本地缓存，压缩逻辑不能阻塞主线程，上报失败时还要有重试机制。它并非神秘的“后台线程”，本质上是浏览器在你空闲时以低优先级调用回调。它并不会创建新线程，也不保证一定会执行——如果页面持续忙碌（比如用户疯狂滚动、动画不停），回调可能被直接跳过，或者延迟到无法预计的时间。

requestIdleCallback 适合做日志压缩上报吗？

适合，但有前提条件：日志必须已本地缓存、压缩逻辑不能阻塞主线程、上报失败需可重试。它不是万能的“后台线程”，而是浏览器空闲时的低优先级回调。requestIdleCallback 本身不创建新线程，也不保证执行——如果页面持续忙碌（比如长按滚动、动画密集），回调可能被跳过或严重延迟。

如何编写一个安全的日志压缩上报循环？

核心思路是“节流 + 分片 + 降级”三件套：避免一次性处理过多日志，撑爆空闲窗口；同时防止某次压缩或序列化超时，导致整个队列卡死。

• 使用 localStorage 或 indexedDB 持久缓存原始日志条目（每条带 timestamp 和 type），不要依赖内存数组，否则刷新页面就会丢失
• 每次 requestIdleCallback 只取最多 50 条日志进行压缩（例如用 lz-string 的 compressToBase64），让单次 CPU 占用控制在 20ms 以内，避免浏览器等待
• 压缩完成后立刻调用 fetch(..., { keepalive: true }) 上报；如果 navigator.onLine === false 或者 fetch 被 reject，就把这批压缩数据存回 indexedDB，下次再试
• 设置 timeout 参数（例如 { timeout: 1000 }），超时就放弃本次回调，等待下一轮空闲窗口

为什么不能在 requestIdleCallback 里直接调用 JSON.stringify？

这个问题比较隐蔽——JSON.stringify 对大对象（比如其中带有堆栈信息、DOM 引用、循环引用的日志）可能会同步卡住好几毫秒甚至更久，直接破坏空闲窗口的稳定性。更危险的是，如果日志里混入了未清理的 Element 或 Window 引用，JSON.stringify 会直接抛出 TypeError: Converting circular structure to JSON，整个回调中断，后续日志全部失效。

• 必须提前清洗日志：删除 __proto__、constructor、函数、Symbol 键、DOM 节点引用等脏数据
• 如果环境支持，优先使用 structuredClone（注意 Safari 16.4+ 才稳定），它比 JSON.stringify 更安全
• 确实需要序列化时，就使用 JSON.stringify(log, (k, v) => typeof v === 'function' || v instanceof Node undefined : v)，至少能兜住大部分异常

移动端 iOS Safari 的兼容性陷阱

iOS Safari 15.4+ 才开始真正支持 requestIdleCallback，而且默认不触发——需要用户交互之后才启用。更要命的是，它对 timeout 参数完全无视，即便设置 { timeout: 100 }，它也会等到真实空闲结束后才执行。这在快速滑动列表时，可能导致上报延迟几十秒，用户体验明显变差。

• 必须检测 typeof requestIdleCallback === 'function'，不支持时降级为 setTimeout(..., 0) + 用 performance.now() 自测空闲状态（简单做法是轮询 event loop 延迟）
• 在 touchstart 或 click 事件之后第一次调用 requestIdleCallback，可以提升 iOS 触发概率
• 不要指望它做时效性强的操作（比如错误现场快照），它只适合“几秒内完成也不晚”的任务

最后提醒一句：空闲回调不是银弹，它完全依赖浏览器的调度策略，而压缩和网络 IO 都可能意外打破空闲假设。最容易被忽视的一点是：没有限制单次 fetch 的 body 大小，导致压缩后仍然超过 64KB，进而触发重试逻辑雪崩——那样就得不偿失了。