断网恢复后自动重试的核心是监听网络状态变化、暂存待重试请求并主动触发重试：利用 navigator.onLine 和 online/offline 事件，离线时用 AbortController 暂存请求至内存队列，联网时通过节流+指数退避重发，并辅以轻量探测和幂等保障。
断网恢复后自动重试待处理的请求，核心在于监听网络状态变化 + 持久化/暂存待重试请求 + 主动触发重试逻辑。关键不是等“重连完成”的某个精确事件，而是检测到网络可用时，立即执行队列中挂起的请求。
监听网络状态变化（onLine / offline）
浏览器原生提供 window.navigator.onLine 属性和 online/offline 事件，是感知网络切换最轻量的方式：
-
offline触发时，把当前失败（或正在发起但可能失败）的请求暂存到内存队列（如Array或Map），并取消原始 fetch/Axios 请求（需支持 abort） -
online触发时，遍历队列，逐个重新发起请求；成功一个就从队列移除一个 - 注意：
navigator.onLine只反映浏览器是否认为联网（例如 Chrome 断 Wi-Fi 会变 false，但连着但 DNS 失败仍为 true），不能 100% 代表服务可达，所以重试逻辑里仍要包含常规错误处理
封装可中断、可重入的请求函数
直接用原生 fetch 或 Axios 发起请求时，必须支持取消机制，否则离线期间发起的请求会在恢复后“意外”完成，造成重复或状态混乱：
- 使用
AbortController控制 fetch 生命周期，在offline时调用controller.abort() - 将每个待重试请求封装成配置对象（含 url、method、body、headers、重试次数、最大重试上限等），而非裸 Promise
- 避免在重试函数里直接
.then()或.catch()，改用 async/await + try/catch，便于统一控制流程和错误降级
管理重试队列与防重复触发
队列本身存在内存中即可（页面未刷新前提下），但要注意并发与重复执行风险：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 用
Set或带唯一 id 的Map存储待重试项，避免同一请求被多次加入 -
online事件可能连续触发多次（尤其在弱网切换时），加一个简单节流：例如设置isRetrying = true标志，重试开始前检查，结束后置为 false - 对每个请求实现指数退避（如 100ms、300ms、900ms），避免瞬间涌出大量请求打爆服务端或触发限流
- 可选：添加超时淘汰机制，比如超过 5 分钟未重试的请求自动丢弃（防止用户长时间离线后回来堆积无效任务）
补充健壮性：主动探测真实连通性
仅依赖 online 事件不够可靠，可在触发重试前加一次轻量探测：
- 发起一个极简 HEAD 请求（如
/health或/ping）到你的 API 域名 - 若探测成功，再批量重试；若失败，延迟几秒后重试探测（避免误判）
- 该探测本身也应可被 abort，且不计入业务请求重试次数
不复杂但容易忽略的是：重试不是“补发”，而是“状态同步”。确保每个请求携带足够上下文（如时间戳、客户端生成 ID），服务端能识别并幂等处理，才能真正安全落地。
