网络恢复后立即有序消费离线队列，需可靠监听online事件并防抖校验、用IndexedDB持久化待同步操作、串行/限并发处理、服务端幂等保障、辅以可见性轮询兜底。
在网络连接恢复的瞬间触发离线队列消费，核心在于**可靠监听网络状态变化** + **确保队列执行不重复、不丢失、不阻塞**。HTML5 本身不提供“连接恢复即刻执行”的原生钩子，需组合使用 navigator.onLine、online 事件和合理的队列调度策略。
监听 online 事件并做防抖与状态校验
online 事件触发快，但不可靠：它可能在浏览器误判（如仅获得本地网络但无外网）或频繁切换时多次触发。不能直接在事件回调里执行同步逻辑。
- 用
setTimeout或requestIdleCallback延迟执行，避开事件风暴 - 必须调用
fetch('/health')或类似轻量接口确认真实连通性，而非只信navigator.onLine - 添加标记位（如
isSyncing = false）防止并发触发
使用 IndexedDB 存储待同步操作，带状态标记
离线操作应写入 IndexedDB，每条记录包含：id、type（create/update/delete）、payload、timestamp、status（'pending' / 'synced' / 'failed'）。
- 同步前只查
status === 'pending'的记录，避免重推已成功但未更新状态的操作 - 同步成功后批量更新状态为
'synced'（推荐事务中 update + delete 组合，更安全） - 失败时保留记录并标记
'failed'，便于后续重试或人工干预
连接恢复后立即启动有序消费，支持中断与续传
不要一次性拉取全部 pending 记录发起并发请求——易触发限流、丢失顺序、难以恢复。
立即学习“前端免费学习笔记（深入）”；
- 采用串行或有限并发（如 Promise.allSettled + 限制 3 个并发）方式逐条/分批处理
- 每条操作完成后更新其状态，再取下一条；任意失败则暂停，记录错误，不跳过
- 加入唯一请求 ID 和服务端幂等键（如
x-idempotency-key），确保重试安全
补充兜底：定时轮询 + 页面可见性判断
依赖 online 事件有盲区（例如页面后台运行时恢复网络，事件可能被忽略）。
- 在页面可见（
document.visibilityState === 'visible'）时，启动一个 30s 间隔的健康检查轮询 - 若发现网络已通且存在 pending 操作，主动触发一次同步流程
- 用户切回页面时也检查一次，覆盖“离线操作 → 切走 → 网络恢复 → 切回”场景
不复杂但容易忽略的是：同步不是“连上了就发”，而是“确认能通、按序处理、留痕可溯、失败可控”。把队列当事务，把网络恢复当信号，而不是命令。
