IndexedDB 缓存外卖订单状态需合理设计结构、版本升级和更新策略：按订单维度存储快照与历史，原子化事务更新，配合 WebSocket 或轮询同步，并设置自动清理与启动比对机制。
IndexedDB 可以很好地缓存外卖订单的实时状态跟踪历史，但关键不是“存数据”，而是设计合理的数据库结构、版本升级逻辑和状态更新策略。它不直接支持推送或监听服务端变更，需配合 WebSocket 或轮询来触发本地更新。
设计适合订单状态跟踪的数据库结构
不要把每次状态变更都当作独立记录硬塞进数据库。应该按订单维度组织，用一个 objectStore 存储每个订单的完整状态快照+变更历史，便于查询最新状态和回溯轨迹。
- 创建名为 orders 的 objectStore，主键设为订单 ID（如
order_id） - 每条记录包含：
order_id、status（当前状态，如 "preparing"）、updated_at（时间戳）、history（数组，存每次变更的 { status, timestamp, remark }） - 添加索引
by_updated_at，方便按时间拉取最近活跃订单
写入和更新订单状态要原子化
避免多次 open + get + put 操作导致竞态。用事务一次性读取旧记录、合并新状态、写回。
- 调用
db.transaction('orders', 'readwrite') - 用
objectStore.get(orderId)获取现有记录 - 在 success 回调里构造新对象：追加新状态到
history，更新status和updated_at - 再调用
objectStore.put(newRecord)写入
从 IndexedDB 快速获取可展示的状态流
用户打开订单页时，不需要遍历整个 history 数组渲染——只需最新状态 + 最近 3 条变更即可。
立即学习“Java免费学习笔记（深入）”；
- 用
get(orderId)直接查单条订单，响应快 - 若需批量加载（如“我的近期订单”），用
openCursor()或getAll()配合index.get()按时间倒序取前 20 条 - 前端渲染时，对
history数组按timestamp降序排列，截取最后 5 项用于时间轴展示
配合网络同步做状态兜底与清理
IndexedDB 是本地缓存，不是权威数据源。必须明确何时该清空、何时该合并、何时该丢弃。
- 订单完成或取消后 7 天，自动用
delete()清理对应记录（可起后台定时任务或下次启动时检查） - App 启动时，先读本地最新状态展示，再发起网络请求比对
updated_at，有更新则覆盖写入 - 若收到 WebSocket 推送新状态，立即更新 IndexedDB；失败时记 log，等网络恢复后重试（简单队列即可）
不复杂但容易忽略：每次数据库结构变更（比如加个字段）都必须升级 version 并在 onupgradeneeded 里重建 store 或迁移数据——否则老用户打开就报错。
