IndexedDB事务确保操作原子性，同一事务内所有操作全成功或全回滚；需指定对象存储和访问模式（readonly/readwrite/versionchange）；必须监听oncomplete/onerror事件判断整体结果，避免异步导致事务提前结束。
IndexedDB 的事务（Transaction）是保证数据操作原子性的核心机制。只要在同一个事务中执行的多个操作，要么全部成功，要么全部失败回滚，不会出现中间状态。
事务的创建和作用域
事务必须基于数据库对象创建，且需明确指定操作的对象存储空间（Object Store）和访问模式：
-
只读事务（
"readonly"）：适用于查询类操作，允许多个并发事务同时进行 -
读写事务（
"readwrite"）：适用于增删改操作，同一时刻每个对象存储只能有一个读写事务活跃 -
版本变更事务（
"versionchange"）：仅在onupgradeneeded中自动触发，用于创建/删除对象存储或索引，会阻塞其他事务
事务的作用域决定了它能操作哪些对象存储。例如：db.transaction(["users", "orders"], "readwrite") 表示该事务可安全地跨两个表做关联写入，且整体具备原子性。
监听事务完成与错误
事务本身不自动提交，也不抛出异常来中断流程——必须显式监听 complete 和 error 事件来确认结果：
立即学习“Java免费学习笔记（深入）”；
-
transaction.oncomplete：所有请求都成功完成时触发，此时数据已持久化 -
transaction.onerror：任一请求失败（如键重复、存储空间不足）时触发，事务自动回滚 -
transaction.onabort：事务被手动中止（transaction.abort()）或因冲突被强制终止时触发
注意：不能只靠单个请求的 onsuccess 判断整体成功，必须依赖事务级事件。例如批量添加用户时，即使前 9 条成功，第 10 条失败也会导致全部回滚。
避免事务意外提前结束
IndexedDB 的事务具有“惰性生命周期”：一旦所有待处理请求都完成（或失败），且没有新的请求被发起，事务就会自动结束。这容易导致意外交互失败：
- 不要在事务内异步发起新请求（如嵌套
setTimeout或未 await 的 Promise），否则事务可能在回调执行前就关闭了 - 所有操作必须基于同一个事务对象的
objectStore()获取存储句柄，不能跨事务混用 - 若需条件分支写入（如“存在则更新，否则插入”），应统一在事务内用
get()+put()组合，并通过onsuccess控制后续逻辑，确保都在同一事务上下文中
典型原子操作示例
比如转账场景：从 A 账户扣款，同时向 B 账户加款，二者必须同时成功或同时失败：
const transaction = db.transaction(["accounts"], "readwrite");
const store = transaction.objectStore("accounts");
<p>// 先查 A 账户余额
const getRequest = store.get("A");
getRequest.onsuccess = () => {
const aBalance = getRequest.result?.balance || 0;
if (aBalance < 100) {
transaction.abort(); // 余额不足，主动中止事务
return;
}</p><p>// 扣 A
store.put({ ...getRequest.result, balance: aBalance - 100 }, "A");</p><p>// 加 B
const bRequest = store.get("B");
bRequest.onsuccess = () => {
const bBalance = bRequest.result?.balance || 0;
store.put({ ...bRequest.result, balance: bBalance + 100 }, "B");
};
};</p><p>transaction.oncomplete = () => console.log("转账成功");
transaction.onerror = (e) => console.error("转账失败", e);
这段代码把两个 put 操作放在同一事务中，即使第二个 put 因网络延迟稍晚发出，只要事务尚未关闭，它们仍属于同一原子单元。
