indexeddb性能优化关键在于批量操作粒度控制与异步流梳理：须在单个readwrite事务内完成批量写入（如一次put 1000条以内），禁用跨事务“伪批量”；所有操作封装为promise，用await链式调用确保顺序，避免回调地狱和race condition；只读用readonly事务，写完立即释放，oncomplete后更新状态。
IndexedDB 的性能优化关键在于两点：控制批量操作的粒度，以及理清异步操作的执行流。它不是单纯“多用 Promise”或“多建索引”就能解决的问题，而是要从事务生命周期、请求并发策略和数据加载节奏上系统设计。
批量写入：合并请求，但别跨事务
批量操作能显著减少 I/O 次数，但必须在同一个 readwrite 事务内完成——跨事务的“批量”只是逻辑分组，无法真正节省开销。
- 用 IDBObjectStore.add() 或 put() 连续提交多条记录，比逐条开启事务快 3–5 倍
- 避免在循环中反复调用 transaction.objectStore().add()；应先收集数据，再统一写入
- 单次事务写入不宜超过 1000 条（具体阈值依数据大小而定），过大易触发浏览器内存回收或事务超时
- 不推荐用 Promise.all() 并发多个 add 请求——它们仍会排队进入同一事务，还可能因异常导致整个事务 abort
异步流控制：用 await 管理依赖，不用回调嵌套
原生 IndexedDB 的事件模型容易造成“回调地狱”，而现代封装应让异步流清晰可读、可中断、可重试。
- 每个数据库操作（open、get、put、delete）都封装为返回 Promise 的函数，拒绝时抛出结构化错误（含 error.name 和 source）
- 需要顺序执行的操作（如“先查再更新”）用 await 链式调用，避免 race condition
- 对非关键路径操作（如日志缓存），可用 setTimeout(() => ..., 0) 或 queueMicrotask 延后执行，防止阻塞主流程
- 游标遍历大数据集时，每次 cursor.continue() 后加 await，避免一次性拉取全部数据撑爆内存
事务模式与生命周期精准匹配
事务不是越长越好，也不是越短越优——它的模式和持续时间必须贴合业务语义。
- 只读查询一律用 "readonly"，即使后续可能触发写操作；不要为图省事复用 readwrite 事务
- 写操作完成后立即释放事务，不要等事件循环空闲；oncomplete 是清理资源的可靠时机
- 监听 onabort 而不只是 onerror，因为事务可能被其他同库操作强制终止
- 升级数据库结构时，upgradeneeded 中只能建表/建索引，禁止执行数据迁移逻辑——那些应放在 upgrade 完成后的独立事务里
结合 Redux Thunk 的协同优化点
当 IndexedDB 作为 Redux 数据源时，状态同步的节奏直接影响渲染性能。
- 避免在 Thunk 内频繁 dispatch 单条记录变更；改用 batchActions 或 React-Redux 的 batch 包裹批量结果
- 从 IndexedDB 读取列表数据后，先做轻量过滤/排序，再整体 dispatch，而非逐条处理再逐条 dispatch
- 写入成功后，可延迟 100ms 再更新 UI 状态（防抖），尤其适用于高频编辑场景（如笔记实时保存）
- 利用 IndexedDB 的 onsuccess 和 oncomplete 差异：前者表示单个请求完成，后者才代表事务真正落盘，关键状态更新应等后者
