离线数据同步的核心是将用户操作以原子日志形式稳存于IndexedDB。每条日志含actionId、targetId、type、payload、timestamp和status字段，写入后由Service Worker按序同步，服务端需幂等处理并返回冲突信息。
离线数据同步的核心不是“等联网再传”，而是把用户操作先稳稳存住、标记状态、按序上行——IndexedDB 就是干这个的可靠底座。
用 IndexedDB 建专用日志仓库，不存原始数据，只记“做了什么”
别把整份文档或订单对象直接塞进数据库。应设计一个 edits_log 或 pending_actions objectStore，每条记录只含必要字段：
- actionId：客户端生成的 UUID（防重复）
- targetId：操作目标标识（如 docId / orderId / chatId）
- type：操作类型（"update_title"、"add_item"、"delete_message"）
- payload：轻量变更内容（例如 { field: "content", value: "新文本" }）
- timestamp：毫秒时间戳（用于后续排序与冲突判断）
- status：初始设为 "pending"，同步成功后改为 "synced"
所有用户动作都封装成原子日志，写入即落盘
每次输入、点击、拖拽、粘贴，只要触发业务逻辑变更，就立即构造一条日志并写入 IndexedDB 事务中：
- 调用
add()或put()时，必须在transaction.oncomplete回调里确认写入完成 - 避免在 UI 交互未结束前就发起网络请求——先存日志，再尝试发送
- 若写入失败（如配额超限），应降级提示用户“暂无法保存编辑”，而非静默丢弃
同步时机交给 Service Worker，前端只管“推日志队列”
页面本身不主动轮询或定时重试。同步由后台机制驱动：
立即学习“前端免费学习笔记（深入）”；
- 页面加载后注册 Background Sync：
navigator.serviceWorker.ready.then(sw => sw.sync.register('sync-actions')) - Service Worker 的
sync事件中，打开 IndexedDB，查询status === "pending"的日志，按timestamp升序提交 - 每条成功响应后，用
put()更新其 status；失败则保留 pending，可加retryCount字段防无限重试
服务端必须配合幂等处理，避免重复执行同一操作
前端日志只是“意图”，最终是否生效由服务端裁定：
- 接口接收
actionId，入库前先查是否已存在，有则直接返回 success - 响应体返回标准结构：
{ success: true, serverVersion: 123, conflict: false } - 若检测到版本冲突（如他人已改过同文档），返回
conflict: true+ 最新快照，前端再决定合并或提醒用户
