网络中断时ajax请求需暂存离线队列并自动重试，核心包括拦截请求存入indexeddb、监听online事件配合健康探测、fifo顺序恢复、幂等性保障及用户可见反馈。
网络中断时，Ajax 请求不能简单丢弃，需暂存待发队列，并在网络恢复后自动重试。核心在于拦截请求、维护离线队列、监听网络状态、按序恢复发送。
拦截请求并加入离线队列
所有 Ajax 请求（如 fetch 或 XMLHttpRequest）应统一经过封装函数处理。该函数先检测 navigator.onLine，若为 false，则将请求参数（URL、method、body、headers 等）序列化后存入 IndexedDB 或 localStorage（推荐 IndexedDB，支持结构化数据和事务）。
- 避免只用内存数组，页面刷新即丢失
- 为每个待发请求生成唯一 ID，便于去重与状态追踪
- 记录时间戳和重试次数，防止无限循环重发失败请求
监听网络状态变化并触发恢复
使用 window.addEventListener('online', ...) 监听上线事件。注意：该事件仅表示系统级联网，不保证服务器可达，因此需配合轻量探测（如 GET /health）确认服务可用后再批量恢复。
- 上线后不立即全量发送，先发一个探测请求验证后端连通性
- 探测成功后，从存储中读取队列，按先进先出（FIFO）顺序逐个发起 fetch
- 每发送一个，检查响应状态；失败则标记、延时重试（如指数退避），成功则从队列中移除
处理重复提交与幂等性保障
离线期间用户可能多次触发同一操作（如点击“提交订单”），若直接重放会导致重复下单。必须在服务端配合实现幂等性：
- 前端在请求头或 body 中带上唯一幂等键（如
X-Idempotency-Key: uuidv4()） - 后端根据该 key 缓存响应结果（如 Redis，TTL 合理设置），相同 key 的后续请求直接返回缓存结果
- 前端队列中对同一业务逻辑（如“创建订单”）可合并或去重，但需谨慎——不是所有操作都适合合并
提供用户可见的离线反馈与控制
用户需要知道当前处于离线状态、有哪些请求待发、是否已恢复。可在 UI 顶部加轻量提示条，并提供“重试全部”“清空队列”按钮。
- 用 橙色提示条 显示“网络不可用，操作已暂存”
- 点击提示条展开待发列表，显示操作类型、时间、状态（等待/发送中/失败）
- 失败请求支持手动重试，或设置最大重试次数后转为“需人工确认”状态
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
