indexeddb事务无显式排队接口，同一object store的readwrite事务严格串行，readonly可并发；需通过oncomplete链式触发实现可靠流水线，避免异步操作导致事务提前关闭。
IndexedDB 本身不提供显式的“事务排队控制接口”，事务的执行顺序由浏览器内部调度机制自动管理，核心规则是：同一对象存储（object store）上，readwrite 事务严格串行执行；readonly 事务可并发，但不阻塞写事务。所谓“任务流水线”，本质是利用这一机制，配合合理的事务创建时机与作用域设计来实现逻辑上的有序执行。
理解事务排队的真实逻辑
多个 readwrite 事务操作同一个 object store 时：
- 第一个事务立即获得锁并执行
- 后续事务不会被丢弃或报错，而是进入等待队列
- 前一个事务完全结束（所有请求完成 + 微任务清空）后，下一个才开始
- 若事务中混入
setTimeout、fetch或await等异步操作，事务会在异步回调触发前就自动关闭——这不是排队失败，而是使用错误
手动构建流水线的关键实践
要让多个操作按预期顺序执行，不能依赖“同时开多个事务”，而应链式触发：
- 在上一个事务的
transaction.oncomplete回调里，再调用下一个事务的创建逻辑 - 或在每个操作请求的
onsuccess中发起后续请求（适用于同事务内多步操作） - 避免跨事务共享未持久化的中间状态；如需传递数据，先读出、再在下一事务中写入
- 对不同 object store 的事务可并行，但若逻辑上有关联（如 A 表更新后才查 B 表），仍需手动串行化
常见误用与规避方式
以下写法看似“流水线”，实则不可靠：
-
db.transaction('store1').objectStore('store1').put(...); db.transaction('store1').objectStore('store1').put(...);→ 两个事务几乎同时创建，第二个会排队，但无法保证你期望的“步骤2一定在步骤1之后提交”——除非监听第一个的oncomplete - 在事务中
await fetch(...)→ 事务早已关闭，后续写入会报 “Transaction inactive” 错误 - 用
Promise.all([tx1, tx2])并发启动 → 若操作同一 store，它们仍排队，但完成顺序不确定，且无法表达先后依赖
轻量级流水线封装建议
可封装一个基于 Promise 的队列执行器：
- 维护一个待执行任务队列（每个任务是一个返回 Promise 的函数）
- 每次只运行队列首项，待其 Promise resolve 后，再取下一项
- 每个任务内部统一用
db.transaction(...)，并在oncompleteresolve，确保事务真正落地 - 这样既保持代码可读性，又严格遵循 IndexedDB 的事务生命周期
