IndexedDB 可作为离线表单同步队列的核心存储，需设计含 status、formPayload、retryCount 等字段的任务记录，配合事务原子更新与索引优化实现可靠状态管理及自动重试。
IndexedDB 可以作为离线任务状态管理的核心存储，配合合理的 schema 设计和事务控制，实现可靠、可恢复的离线表单同步队列。关键不在于“存数据”，而在于明确每个任务的生命周期状态、失败重试逻辑和幂等性保障。
设计带状态字段的任务记录结构
每个待上传的表单提交任务应存为一条 IndexedDB 记录，至少包含以下字段：
- id：唯一标识（可用 UUID 或时间戳+随机数，避免多端冲突）
-
status：枚举值，如
"pending"（未尝试）、"uploading"（正在上传）、"succeeded"（成功）、"failed"（失败需重试）、"discarded"（手动丢弃） - formPayload：原始表单数据（JSON 序列化前对象，存为 JS 对象更安全）
- retryCount：已重试次数（用于限制最大重试，比如 ≤3）
- lastAttemptAt：上一次尝试时间（毫秒时间戳，用于退避重试或超时清理）
-
errorInfo：最近一次失败的简要信息（如
"NetworkError"、"401 Unauthorized"，不存完整堆栈）
建议用 versionchange 升级时添加索引：store.createIndex("status-retry", ["status", "retryCount"])，方便快速查出所有 pending 或 failed 且可重试的任务。
上传时原子更新状态 + 错误回滚
发起上传前，必须在同一个事务中完成「状态标记为 uploading」和「读取 payload」——避免多个标签页/Service Worker 同时处理同一任务：
立即学习“Java免费学习笔记（深入）”；
- 用
readwrite事务打开 store - 先用
get()或openCursor()查找一条status === "pending"的记录 - 立刻调用
put()将其status改为"uploading"（并更新lastAttemptAt） - 再读取该记录的
formPayload发起网络请求 - 若上传成功 → 再次
put()设为"succeeded"；若失败 →put()设为"failed"并递增retryCount
整个流程不 commit 事务前，其他上下文查不到该任务的中间态，保证状态一致性。
后台自动同步：定时扫描 + 智能重试策略
不要依赖用户刷新页面触发同步。推荐在 Service Worker 中用 setInterval（或基于 fetch 事件唤醒）定期检查：
- 查询
status = "pending"的任务 → 立即尝试上传（新任务优先） - 查询
status = "failed" AND retryCount 的任务 → 检查 <code>lastAttemptAt是否已过退避窗口（如 30s、2min、10min 指数退避）再上传 - 对
status = "succeeded"的任务，可保留 24 小时后自动清理（防止 DB 膨胀）
注意：Service Worker 中使用 IndexedDB 需确保数据库已 open（监听 statechange 或封装初始化逻辑），且所有操作必须在 self.addEventListener('fetch', ...) 或定时回调内完成。
用户可见的状态反馈与手动干预
前端 UI 应实时反映队列状态，例如在设置页显示「3 个待同步」「1 个上传失败」，并提供操作入口：
- 点击「重试失败项」→ 找到所有
status === "failed"记录，批量设为"pending" - 点击「清空已成功项」→ 删除
status === "succeeded"的记录（确认弹窗防误触） - 表单提交后立即写入
"pending"记录，并在 UI 显示「已保存至离线队列」，而非「已提交」
所有用户操作也必须走 IndexedDB 事务更新，避免状态与 UI 脱节。可搭配 localStorage 做轻量同步提示（如 badge 数字），但真实状态只以 IndexedDB 为准。
本质上，IndexedDB 在这里是“离线任务的状态账本”，不是临时缓存。只要 schema 清晰、事务严谨、重试可控，就能支撑从断网填写到弱网恢复的全链路可靠性。
