IndexedDB事务不支持自动链式依赖，必须在单个事务内手动编排“读→判断→写”逻辑；跨事务无法传递状态，所有操作需共用同一transaction实例并确保原子性。

IndexedDB 事务本身不支持“链式依赖”或“前序结果驱动后续操作”的自动延续。所谓“依赖前序操作”，比如先查一条记录、根据其字段值决定是否新增或更新，这类逻辑必须由开发者手动编排在**同一个事务生命周期内完成**——不是靠事务机制自动串联，而是靠代码顺序与事件回调控制。

为什么不能跨事务传递依赖逻辑

事务不具备状态记忆能力。一旦一个 readwrite 事务因所有请求完成而自动提交（或因错误 abort），它就彻底结束。下一个 db.transaction() 创建的是全新事务，与之前无任何数据上下文关联。常见误区包括：

• 在第一个事务的 oncomplete 里再开新事务去处理上一步结果 —— 这两个事务完全独立，中间若页面刷新或脚本中断，就会丢失衔接
• 把查询结果存在变量里，然后 setTimeout 或 Promise.then 中发起写操作 —— 此时原事务早已失效，objectStore 引用会抛 TransactionInactiveError
• 用 async/await 包裹多个 store.add() 调用，误以为它们共享事务 —— 实际每个 await 等待的是独立 request，但若没显式共用同一 transaction 实例，很可能分散在多个事务中

正确实现前序依赖的操作模式

核心原则：把“读 → 判断 → 写”三步压缩进**单个事务的一次事件循环中**，且所有 request 都源自该事务的 objectStore。

• 用 transaction.objectStore('store').get(key) 发起查询，立即在其 onsuccess 回调里做判断并发起后续 add/put/delete
• 如果需批量依赖（如查出 N 条，每条决定是否更新），改用游标遍历：objectStore.openCursor()，在每个 cursor.onsuccess 中检查 cursor.value 并同步调用 cursor.update() 或 transaction.objectStore(...).put()
• 避免在 onsuccess 外部保存 objectStore 引用；每次操作都重新取：transaction.objectStore('store') —— 它轻量且安全

处理条件写入与冲突回退

当依赖判断结果执行写入，又希望失败时不破坏已有状态，可结合 ConstraintError 主动控制流程：

• 例如：查用户是否存在，存在则更新邮箱，不存在则新建。可在 put() 的 request.onerror 中捕获 ConstraintError，然后改用 add()，或反之
• 注意不要调用 event.preventDefault() 后继续发其他 request —— 这不会让事务“续命”，反而可能因事务已 inactive 导致后续操作静默失败
• 更稳妥的方式是：先 get()，拿到结果后，在同一个 onsuccess 里明确调用 add() 或 put()，避开键冲突场景

多对象仓库间的依赖操作

若逻辑跨越多个 store（如“订单创建成功后，扣减对应商品库存”），必须用多 store 事务声明：

• 创建事务时显式列出：db.transaction(['orders', 'products'], 'readwrite')
• 分别获取各自 store：const orderStore = tx.objectStore('orders');，const productStore = tx.objectStore('products');
• 所有读写都在这个 tx 内完成，确保原子性：任一环节失败，两个 store 的变更全部回滚