IndexedDB事务一致性靠自动中止与回滚保障：必须显式创建事务并绑定所有操作，监听transaction.onerror而非单个请求错误，避免跨异步边界使用，且批量操作应合并至单个readwrite事务以确保原子性。

IndexedDB 本身不提供显式的“提交”或“回滚”API，事务的一致性靠自动机制保障：只要操作出错且未被拦截，整个事务就会自动中止并回滚。关键在于正确创建事务、绑定操作、监听错误，并避免常见陷阱。

事务必须显式创建并指定作用域

所有读写操作都必须在事务内进行，不能脱离事务直接调用 add()、put() 等方法。创建时需明确：

• 涉及的对象仓库名称（数组形式），例如 ['users', 'orders']
• 访问模式：'readonly' 或 'readwrite'（'versionchange' 仅用于数据库升级）

错误示例：漏传对象仓库名、传入不存在的仓库、在 readonly 事务里调用 add() —— 这些都会立即触发 onerror 并中止事务。

错误未捕获 = 自动回滚

IndexedDB 的回滚是隐式且不可逆的。只要事务中任意请求（如 add() 报 ConstraintError，或 get() 读取失败）抛出未处理的错误，事务就会中止，之前所有变更全部丢弃。

• 务必为事务监听 onerror，而不是只监听单个请求的错误
• 不要在错误回调里调用 event.preventDefault()，否则可能阻止默认回滚行为
• 若需部分容错（如跳过某条非法数据），应在发起请求前校验，而非依赖事务内“吞掉错误”

事务生命周期不可控，禁止跨异步边界使用

事务在事件循环空闲时自动关闭，无法手动延长时间。以下操作会导致事务提前失效或报错：

• 在 setTimeout、Promise.then 中继续使用已创建的 objectStore
• 把事务对象或其 objectStore 引用保存到外部变量，之后再调用方法
• 在事务未完成前重新打开数据库或执行其他事务

正确做法：所有操作链必须在同一个同步上下文内完成，或用 async/await 配合 Dexie.js 等封装库管理生命周期。

批量操作尽量合并到单个读写事务

多个独立事务不仅性能差，还可能因执行顺序引发逻辑不一致。例如转账场景：扣款和记账必须原子执行。

• 用一个 'readwrite' 事务操作所有相关对象仓库
• 避免先在一个事务里更新 A，再另起事务更新 B —— 中间若页面崩溃，A 已改而 B 未动
• Dexie.js 等库可进一步简化，它自动包装 Promise 并确保事务内所有 await 操作属于同一上下文