IndexedDB 的异步请求不保证执行顺序，需通过事务隔离、Web Locks API、批量操作和独立错误处理来保障数据一致性。
IndexedDB 的异步请求本身不保证执行顺序，多个并发请求可能因网络延迟、事务生命周期或回调调度差异，导致数据写入错乱、状态覆盖或读写冲突。关键不是“控制请求发起顺序”，而是**约束执行上下文与资源访问边界**。
事务隔离是基础防线
每个读写操作必须明确归属一个事务，且不能跨事务共享中间状态：
- 同一事务内，所有请求按代码调用顺序排队执行，自动保障原子性；
- 不同事务之间无执行顺序保证，尤其当它们操作同一对象存储时，后提交的事务可能覆盖先提交的结果；
- 避免在事务外缓存 request 对象或游标，IDBRequest 和 IDBCursor 都是一次性凭证，事务结束即失效。
用 Web Locks API 控制逻辑串行
当多个异步操作需按序修改同一份数据（如计数器更新、用户配置同步），仅靠事务不够，需主动加锁：
- 为关键资源分配唯一锁名，例如
'user-profile-write'； - 用
navigator.locks.request(lockName, callback)包裹写操作，回调返回 Promise 后锁自动释放； - 并发请求会自动排队，前一个完成，下一个立即进入，避免竞态和跳序。
批量操作优先于逐条请求
频繁触发单条 put/get 容易放大时序不确定性，应合并处理：
- 遍历数据时，先用只读事务 + 游标收集所有待更新的 key 或完整数据；
- 再开启新 readwrite 事务，集中调用
put()或delete()，减少事务切换次数； - 避免在游标回调里启动 fetch 或 setTimeout——这些异步任务返回时，原事务大概率已关闭。
错误必须绑定到 request 而非事务
事务中任一 request 失败，默认触发整个事务 abort，但错误捕获点容易错位：
- 每个
request.onerror必须独立设置，不能只监听 transaction.onerror； - 未捕获的 request 错误会静默中止事务，导致部分写入成功、部分丢失；
- 若需部分失败仍继续，应在 request.onerror 中显式调用
transaction.abort()并重新组织流程。
