indexeddb离线同步核心是状态可追踪、失败可重试、冲突可处理:设计含status等元信息的数据结构;监听online事件并结合fetch校验后逐条上传;对失败记录按指数退避重试且限制次数;通过唯一clientid和服务端幂等保障防重复。

IndexedDB 实现离线同步上传,核心思路是:先在本地数据库中缓存待上传的数据(带状态标记),网络恢复后自动尝试上传,成功后更新或删除本地记录。关键不在“一次写完”,而在“状态可追踪、失败可重试、冲突可处理”。
1. 设计带同步状态的数据结构
不要直接存业务数据,而是包装一层元信息,用于判断是否已同步、是否需要重试:
- 字段如:
id(唯一标识)、data(原始业务对象)、status("pending"/"syncing"/"synced"/"failed")、createdAt、updatedAt、retryCount(避免无限重试) - 示例存储对象:
{ id: "uuid-123", data: { title: "笔记标题", content: "正文..." }, status: "pending", createdAt: Date.now(), retryCount: 0 }
2. 网络监听 + 自动触发同步队列
监听 online / offline 事件,但注意:浏览器的 online 事件只表示网络接口通,不保证服务器可达。建议结合 fetch 超时和错误码二次确认:
Java项目代码review工具。分析Git变更+完整调用链路上下文,推断业务需求,进行多维度评分和分类汇总,生成完整PRD文档。包含细粒度Java代码审查清单(Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用
window.addEventListener('online', startSync)启动同步流程 - 同步函数应逐条取出
status === "pending"的记录,按顺序上传(避免并发压垮服务端) - 每条上传后根据响应更新本地状态:成功则设为
"synced"并可选删除;失败则设为"failed",并增加retryCount
3. 处理上传失败与重试策略
网络波动常见,需避免频繁无效请求:
- 对
retryCount > 3的记录暂停自动重试,标记为"failed",留待用户手动触发或后续智能策略处理 - 使用指数退避(如首次 1s 后重试,第二次 2s,第三次 4s)——可在定时器中实现,不阻塞主流程
- 上传前检查
navigator.onLine,但不依赖它作为唯一依据;真正上传时用fetch(...).catch()和 HTTP 状态码(如 5xx)判断失败
4. 防止重复上传与幂等性保障
服务端必须支持幂等操作(例如通过客户端生成的唯一 requestId 或数据 id 判重):
- 前端在生成待同步数据时,就生成唯一
clientId或复用业务主键,传给后端 - 后端收到重复
clientId时直接返回成功,不重复写库 - 前端上传成功后,即使 IndexedDB 删除失败,下次同步仍能跳过已标记
"synced"的项,不会重复提交
不复杂但容易忽略:同步不是“有网就全发一遍”,而是“按状态驱动、逐条可控、失败隔离、服务端兜底”。把状态管理做扎实,离线体验才真正可靠。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










