indexeddb 的事务是强制执行环境，所有操作必须在显式创建的事务中进行，事务懒启动、自动提交回滚，具备原子性与读写锁机制。
IndexedDB 的事务不是可选功能，而是所有数据操作的强制执行环境。离开事务，任何增、删、改、查都无法进行——这是它保障原子性与一致性的根本前提。
事务必须显式创建并绑定对象仓库
每次操作前都要调用 db.transaction()，明确指定参与的对象仓库名称和访问模式（readonly 或 readwrite）。一个事务可同时操作多个对象仓库，但所有操作都必须基于该事务获取的 objectStore 实例：
- 不能复用其他事务创建的 store 实例
- 不能在事务外直接调用 store.add()、store.get() 等方法
- versionchange 事务仅在数据库升级时自动触发，不可手动创建
事务生命周期由请求驱动，不跨事件循环
事务是“懒启动”的：只有在其内发起第一个请求（如 get、add）时才真正激活。它不会因 setTimeout、Promise.then 等异步延迟而延续——一旦当前任务结束，事务即失效：
- 在 setTimeout 回调中使用已结束事务的 store 会报 “Transaction is inactive” 错误
- 所有相关操作应集中在同一同步代码块或连续 Promise 链中完成
- 事务自动提交，无需手动 commit；失败则自动回滚
错误处理决定事务成败
事务具备强原子性：任一请求失败（如 ConstraintError、AbortError），整个事务立即中止，已执行的操作全部回滚。因此必须监听关键事件：
- onerror：捕获底层错误，但不阻止事务继续尝试后续请求
- onabort：事务被主动中止或因错误回滚时触发，适合清理或重试逻辑
- oncomplete：仅当所有请求成功且无 abort 时触发，表示数据已持久化
读写锁机制影响并发行为
IndexedDB 内部采用读写锁控制并发访问：
- 多个 readonly 事务可同时运行，互不阻塞
- readwrite 事务会独占所涉及的对象仓库，阻塞其他 readwrite 事务及后续 readonly 事务
- 避免长时间持有 readwrite 事务，尤其不要在其中执行耗时计算或网络请求
