HTML5离线同步需Service Worker拦截请求、IndexedDB结构化暂存、Background Sync自动补发三者协同：SW在fetch中阻断POST并写入IDB，IDB用事务与索引保障数据安全，Background Sync在sync事件中重试并更新状态，配合幂等接口与用户反馈实现可靠同步。
HTML5 中离线数据同步要真正可靠，不能只靠“检测到没网就存 localStorage”这种简单做法。核心在于 Service Worker 主动拦截请求、配合 IndexedDB 持久化暂存、再由 Background Sync 自动补发——三者各司其职，缺一不可。
Service Worker 必须接管请求生命周期
它不是被动监听，而是作为网络代理全程参与：
- 在 fetch 事件中识别待同步的 POST 请求（比如 /api/order/submit），不直接转发，而是先阻断并标记为“需离线处理”
- 对这类请求，不返回 fetch() 结果，也不抛错，而是立即触发 IndexedDB 写入逻辑（注意：SW 中不能直接调用 indexedDB.open()，应由页面提前初始化好 DB 实例并暴露给 SW 通信）
- 写入成功后，返回一个模拟的成功响应（如 { code: 0, message: "已暂存，网络恢复后提交" }），避免前端逻辑中断或报错跳转
IndexedDB 负责结构化暂存，不是备份容器
它承担的是事务安全与可查可控的数据暂存职责：
- 建独立 objectStore（如 orders_pending），字段至少含 id（推荐 crypto.randomUUID()）、data（JSON 字符串）、status（'pending'/'syncing'/'failed'）、created_at、retry_count
- 所有写入必须包裹在 readwrite 事务中，防止用户快速连点提交导致多条重复记录
- 支持按 status + created_at 建复合索引，方便 Background Sync 触发时高效拉取最早未同步项
Background Sync 是真正的“自动补发引擎”
它让同步脱离用户操作依赖，由浏览器在合适时机唤醒 SW 执行：
立即学习“前端免费学习笔记（深入）”；
- 主线程注册：navigator.serviceWorker.ready.then(sw => sw.sync.register('sync-orders'))，标签名必须唯一且语义明确
- 在 SW 的 sync 事件中读取 IndexedDB，逐条发起 fetch，用 event.waitUntil() 包裹整个异步链路
- 同步成功后更新 status 为 'synced' 并写入 server_order_id；失败则递增 retry_count，status 设为 'failed'，保留原始记录供排查
用户侧反馈和兜底判断不能只靠 navigator.onLine
这个 API 响应滞后且不准，必须结合实际请求结果：
- 提交订单时，fetch 失败（网络异常、5xx、超时）即视为离线场景，立刻走 IndexedDB 暂存流程
- UI 层显示「已暂存，将在后台自动提交」，并提供「查看暂存订单」入口，列出 pending 订单摘要及手动重试按钮
- 服务端接口必须支持幂等：以客户端传入的 id 为唯一键，用数据库 UPSERT 或先 SELECT 后 INSERT 确保重复提交不产生脏数据
