HTML5离线订单暂存与同步需Service Worker、IndexedDB和Cache API协同：IndexedDB可靠暂存订单，Service Worker通过Background Sync自动同步，UI提供状态反馈，服务端配合幂等处理。
在HTML5中实现离线订单暂存与同步，核心是利用 Service Worker + Cache API + IndexedDB 三者协同：用 IndexedDB 可靠存订单数据，Service Worker 拦截网络请求并管理同步逻辑，Cache API 可选缓存静态资源提升离线体验。
用 IndexedDB 可靠暂存订单数据
IndexedDB 是浏览器中唯一支持大量结构化数据、事务性写入的本地数据库，适合暂存未提交的订单。关键点：
- 创建独立 objectStore（如
orders_pending），字段至少包含id、data（JSON序列化订单）、status（'pending'/'synced'）、created_at - 所有写入必须封装在事务中，避免部分失败导致数据不一致；例如用户点击“提交”时，先写入 IndexedDB，再尝试网络请求
- 为避免重复提交，可生成客户端唯一 ID（如 UUID v4）作为订单主键，并在服务端做幂等校验
Service Worker 主动管理同步时机
不能依赖用户手动刷新或重进页面来触发同步。应使用 Background Sync API（需 HTTPS + Chrome/Edge 等支持）自动调度：
- 在页面中注册 sync 事件：
navigator.serviceWorker.ready.then(sw => sw.sync.register('sync-orders')) - 在 Service Worker 的
sync事件监听器中，从 IndexedDB 读取 status = 'pending' 的订单，逐条 POST 到后端接口 - 同步成功后更新对应记录的
status为 'synced'；失败则保留 pending，下次 sync 再试（可加重试计数防止死循环）
离线时平滑降级与用户反馈
用户无感知的离线体验需要明确的状态提示和可控的操作逻辑：
- 通过
window.navigator.onLine监听网络状态变化，但注意它仅反映系统级连通性，实际应结合 fetch 请求失败兜底判断 - 提交订单时若检测到离线或请求失败，立即写入 IndexedDB，并在 UI 显示「已暂存，网络恢复后自动提交」提示
- 提供「查看暂存订单」入口，列出 pending 订单摘要（时间、金额、状态），支持手动重试或取消
服务端配合：接收、去重、返回最终状态
前端同步机制必须和服务端协作才能闭环：
- 后端接口需接受客户端生成的订单 ID，并基于该 ID 实现幂等写入（如用数据库唯一约束 + UPSERT 或先查后插）
- 响应中返回标准结构，含
success: true/false、message、server_order_id（用于后续查询） - 同步成功后，前端应更新 IndexedDB 中对应记录，补充
server_order_id和synced_at，便于追溯
不复杂但容易忽略：每次同步前检查 IndexedDB 连接是否仍有效（尤其长时间后台后），同步完成后主动关闭 DB 连接释放资源；同时建议对 pending 订单设置过期时间（如 7 天），避免本地堆积无效数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
