IndexedDB 事务异步回调结束后为什么自动提交

很多 IndexedDB 的“偶发写不进去”，根源不是 put() 丢数据，而是把事务误当成了可以跨任意异步操作长期持有的连接。readwrite 事务在当前事件任务里没有新的请求时，就可能结束活动状态并自动提交；await 之后再拿旧的 tx 写入，常见结果就是 TransactionInactiveError。

要保证一批写请求属于同一个事务，就在事务仍然活动的请求回调中连续排队；如果中间必须等待网络、定时器或 Promise，再把流程拆成读事务和新的写事务。

IndexedDB 为什么会在 await 之后自动提交

IndexedDB 把一次读写操作放进 IDBTransaction，再通过 object store 产生一个个 IDBRequest。事务只在“活动”时接受新的请求。当当前事件任务中的请求已经处理完，又没有新的请求排队，浏览器就可以让事务进入提交阶段。提交是自动的，不需要也不能用 SQL 式的手动 commit 来延长它。

await 会把后续代码安排到稍后的 Promise 任务。即使暂停时间很短，原来的事务也可能已经没有活动请求。下面这种写法的问题在于，tx 的 JavaScript 引用还在，但它代表的事务生命周期不一定还在：

const tx = db.transaction("notes", "readwrite");
const store = tx.objectStore("notes");
store.put({ id: 1, text: "草稿" });

await getExtraText(); // 中文注释：跨出当前事件任务，事务可能已失活
store.put({ id: 1, text: "完整草稿" }); // 可能抛出 TransactionInactiveError

连续写入要放在同一个活动窗口里

如果数据已经在内存中，最稳妥的办法是先打开事务，再在同一个同步调用段里连续发出请求。不要把每次 put() 包成一个需要等待的 Promise；等待单个请求完成后，再安排下一次写入，可能已经错过事务活动窗口。

function saveNotes(db, notes) {
  return new Promise((resolve, reject) => {
    // 中文注释：一次事务覆盖整批 object store 写入
    const tx = db.transaction("notes", "readwrite");
    const store = tx.objectStore("notes");

    // 中文注释：数据已准备好，在当前活动窗口连续排队请求
    for (const note of notes) store.put(note);

    // 中文注释：事务事件才代表整批写入的最终结果
    tx.oncomplete = () => resolve();
    tx.onerror = () => reject(tx.error);
    tx.onabort = () => reject(tx.error || new Error("事务已回滚"));
  });
}

这里的关键不是“少写几个 await”，而是把所有请求放在同一活动窗口，并把错误归属到事务。单个 request 的成功只能说明该请求被处理，后续请求仍可能让整个事务回滚。

必须跨异步边界时，为什么要拆成两个事务

真实业务经常需要先从 IndexedDB 读出草稿，再等待网络返回或计算结果，最后写回。此时不要让第一个读事务陪你等待。先在读事务的请求回调中拿到数据，等异步工作完成后重新创建一个写事务。

async function enrichAndSave(db, id) {
  const note = await readNote(db, id); // 中文注释：读事务在 readNote 内完成
  const extra = await getExtraText(); // 中文注释：异步准备不持有旧事务

  return new Promise((resolve, reject) => {
    // 中文注释：异步结果准备好后，重新打开短生命周期写事务
    const tx = db.transaction("notes", "readwrite");
    tx.objectStore("notes").put({ ...note, extra });
    tx.oncomplete = resolve;
    tx.onerror = () => reject(tx.error);
    tx.onabort = () => reject(tx.error || new Error("写入已回滚"));
  });
}

拆分后要接受一个事实：读到的数据可能已被其他事务更新。若业务要求“读取、判断、写回”不可被插入，就需要重新设计数据模型，或在同一活动窗口内完成判断和写入，而不是靠跨 await 保留事务。

用事务事件判断提交结果

建议把 request.onsuccess 当作“这一项请求完成”，把 tx.oncomplete 当作“整个事务完成”。批量导入、覆盖写入或多 store 更新尤其要等事务完成后再更新界面，否则页面可能提前显示成功。

排查时先检查三件事：是否在 await、setTimeout 或网络回调后复用了旧事务；是否把一个 request 成功当成批量成功；是否为读写操作分别设置了事务级错误处理。不要用延时“碰运气”延长事务，应该缩短事务或明确拆分。

常见问题

为什么 request 成功了，事务还是失败？

request 成功只覆盖单个请求。另一个请求失败、约束冲突或显式 abort 都可能让事务整体回滚，最终以 tx.onerror、tx.onabort 和 tx.oncomplete 为准。

能不能手动调用 tx.commit() 解决自动提交？

commit() 只能提前启动提交，不能把已经失活的事务重新变成活动状态，也不能跨 await 延长生命周期。需要异步准备数据时，应重新打开事务。

把所有操作都放进一个大事务更安全吗？

不一定。大事务会扩大锁定和失败范围；数据已准备好时可批量写入，涉及网络或长计算时则应拆分，并额外处理读写之间的数据竞争。