IndexedDB异步操作依赖事务与请求的时序关系而非链式调用；关键在于复用事务、合理建索引、批量写入及分层错误处理，以提升性能与可靠性。

IndexedDB 的异步操作链本身不是“链式调用”，而是基于事务（transaction）和请求（request）的时序依赖关系构建的可靠执行流。真正影响性能的，不是写法是否链式，而是如何组织这些异步步骤、避免嵌套陷阱、合理复用事务，并配合索引与批量处理释放数据库潜力。

事务复用：减少开销的关键

每次新建 transaction 都有初始化成本，尤其在高频写入场景下容易成为瓶颈。应尽可能把多个读/写操作合并进同一个事务中，而不是为每个操作单独开启一个。

• ✅ 正确做法：同一 transaction 内连续调用 objectStore.add()、objectStore.put()、index.get()
• ❌ 反模式：每调用一次 API 就 new 一个 transaction，导致大量重复上下文切换
• 注意：事务生命周期绑定于其内所有 request 的完成；任一 request 失败会回滚整个事务

索引驱动查询：让 where 不再慢

IndexedDB 的查询性能几乎完全取决于索引设计。没有索引的 get() 或 openCursor() 在大数据量下是全表扫描，而合理索引可将 O(n) 降为 O(log n)。

• 对常用过滤字段建非唯一索引，如 status、userId、createdAt
• 复合索引适用于多条件联合查询，例如 store.createIndex('byStatusAndTime', ['status', 'createdAt'])
• 创建索引应在 onupgradeneeded 中完成，且仅在版本升级时执行一次

批量写入 + Redux Thunk 协同优化

当业务需要一次性插入/更新数百条数据（如离线缓存同步），直接循环 dispatch 会导致大量独立事务和状态抖动。结合 Redux Thunk 的批量能力可显著提效。

• 在 Thunk 内部统一打开 DB 连接，用单个 transaction 批量写入
• 使用 batch()（React-Redux 提供）包裹多个 dispatch，避免中间状态触发多余渲染
• 写入完成后，再 dispatch 一个 success action 更新 UI，实现“一次更新、一次渲染”

错误隔离与降级策略

IndexedDB 操作失败不等于应用崩溃。需建立分层容错机制：

• 单个 request 失败：捕获 request.onerror，记录日志，跳过该条数据，继续后续操作
• 事务失败（如 quota exceeded）：退回到内存缓存（如 Map）暂存，待空间释放后重试
• DB 初始化失败：提供轻量 localStorage 回退方案，保障基础功能可用