离线缓存同步失败后的后台重试需分离同步动作与网络请求，将待同步操作持久化至indexeddb的pendingsync存储区，包含操作类型、api路径、时间戳、重试次数等字段，并通过online事件、service worker激活、页面可见性等事件驱动重试，配合指数退避策略（1s、2s、4s…最多5次）控制重试节奏。

离线缓存同步失败后的后台重试，核心在于分离“同步动作”和“网络请求”，把待同步的数据持久化到本地（如 IndexedDB），再由独立的重试机制按策略发起网络请求。不是靠 setInterval 轮询，而是用更可靠、可控的方式驱动重试。

用 IndexedDB 持久化待同步的操作

用户在离线时产生的增删改操作（比如提交表单、标记已读），不能只存在内存或 localStorage（容量小、无事务、无法存复杂对象）。应统一写入 IndexedDB 的一个叫 pendingSync 的 objectStore 中，每条记录包含：

• 操作类型（create/update/delete）
• 目标 API 路径和请求体（JSON 序列化后存）
• 时间戳、唯一 ID、重试次数、最后失败原因（可选）
• 是否已标记为“成功同步”（用于幂等清理）

写入时开启事务并监听 complete/error，确保落盘成功才认为“已排队”，避免丢失。

监听网络状态 + 主动触发重试

不依赖定时轮询，而是结合事件驱动：

• 监听 window.addEventListener('online', ...)：网络恢复时立即启动一次重试
• 监听 serviceWorker.controller.onstatechange（若用了 SW）：SW 激活后也可触发
• 页面可见时（document.visibilityState === 'visible'）检查并重试，避免后台标签页浪费资源

注意：online 事件不保证网络真正可用（可能连的是无外网的 WiFi），所以每次重试前仍需加 fetch 超时和错误捕获。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

实现带退避策略的重试逻辑

直接反复重试会加重服务器压力，也易被限流。推荐指数退避（exponential backoff）：

• 首次失败：1 秒后重试
• 第二次失败：2 秒后
• 第三次失败：4 秒后
• 最多重试 5 次，之后标记为“永久失败”，通知用户手动处理

退避时间可存入 IndexedDB 记录中，每次失败更新 nextRetryAt 字段；重试任务从 DB 中查出 nextRetryAt ≤ now 且 retryCount 的记录执行。

确保请求幂等性与服务端协同

前端重试必须和服务端配合，否则重复提交会导致脏数据：

• 每个待同步操作生成唯一 clientID（如 crypto.randomUUID()），随请求一起发给后端
• 后端根据 clientID 做去重判断（如 Redis 缓存 24 小时内已处理的 clientID）
• 响应中返回明确状态：{ success: true, syncedAt: '...' } 或 { success: false, reason: 'conflict' }
• 前端收到成功响应后，从 IndexedDB 中删除该 pending 记录；失败则更新 retryCount 和 nextRetryAt

不复杂但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南