indexeddb 事务一旦创建，其作用域、模式和生命周期即固定，无法动态添加请求或监听器，所有操作须在事务活跃期内同步发起，否则抛出 invalidstateerror。
HTML5 的事务（transaction）概念主要出现在 IndexedDB 中，而非 HTML5 本身定义的通用“事务”机制。在 IndexedDB 中，事务（IDBTransaction）一旦创建并开始执行，其作用域（object stores）、模式（只读/读写）和生命周期就已确定，**无法在事务进行中动态添加新的请求或处理逻辑**。
事务对象不可动态扩展
IndexedDB 事务是惰性执行、一次性声明的。所有数据库操作（如 get、put、delete）必须在事务创建后的“当前事件循环阶段”内通过 transaction.objectStore(...).xxx() 显式发起。一旦当前 JavaScript 执行栈清空（例如离开回调函数、进入下一个微任务），事务就进入“等待提交或自动完成”状态：
- 未被阻塞的只读事务会在最后一个请求完成时自动完成；
- 读写事务需显式等待所有请求结束，但不会接受新发起的请求；
- 若在事务活跃期之外（如 setTimeout、fetch 回调、Promise.then 中）再调用 objectStore 方法，会直接抛出
"InvalidStateError: Transaction is inactive or scope is not valid"。
不能中途插入新请求或监听器
事务实例不提供类似 transaction.on('requestAdded', ...) 或 transaction.enqueue(...) 的 API。所有请求必须在事务上下文仍有效时同步注册：
- 无法在某个
request.onsuccess回调里再发一个属于同一事务的新请求（除非该回调仍在原事务的同步执行流中，且 objectStore 引用依然有效）； - 无法为已发出的请求动态追加
onerror或修改其处理逻辑； - 事务的
oncomplete、onabort、onerror事件监听器也必须在事务创建后立即绑定，延迟绑定可能错过事件。
常见误用与替代方案
开发者有时试图“动态决定下一步操作”，例如根据某条记录内容决定是否写入另一条数据。此时应避免强行塞进同一事务，而采用更健壮的设计：
- 提前规划事务范围：在发起事务前，先收集所有要读/写的 key 和数据，统一在事务内批量处理；
- 拆分为多个事务：先读取判断，再开启新事务执行后续操作（注意：这会失去原子性，需业务层容错）；
- 使用 Promise 封装链式流程：用 async/await 清晰表达依赖关系，每个事务独立，逻辑清晰易维护；
- 服务端协调（如适用）：复杂业务逻辑尽量下沉，前端只负责确定性操作。
IndexedDB 的事务模型强调明确性与可预测性，不支持运行时动态编织逻辑。理解其“声明即固定”的特性，是写出稳定离线存储代码的关键。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
