IndexedDB 事务为何不能跨 await

IndexedDB 事务不能稳定跨过 await，关键不在于 await 这个语法本身，而在于它通常会把后续代码放到另一个事件循环任务。事务只在创建它的任务、以及某个请求的 success/error 回调中保持 active；回到事件循环后，如果没有新的请求，浏览器就可能自动提交。于是，await 后再调用 store.put()，常见结果就是 TransactionInactiveError。

实用判断：异步准备放在事务外；同一事务内的数据库请求尽量连续发出，或在上一个请求的事件回调中继续发出。不要先创建 readwrite 事务，再等待网络、定时器或另一个 Promise。

IndexedDB 事务为什么会在 await 后失活

一个事务刚创建时是 active，创建任务结束后会进入 inactive；请求完成时，浏览器会在该请求的事件处理任务里短暂恢复 active。这个时间窗口允许你继续调用 get、put 或 delete。事件处理函数返回后，如果没有新的请求，事务就具备自动提交条件。

await 会暂停当前 async 函数，等 Promise settled 后再安排 continuation。即便 Promise 很快完成，也不能把它当作仍在同一个 IndexedDB 请求回调里。setTimeout、网络请求和大多数独立异步操作更明显：它们返回事件循环后，原事务已经可能提交或失活。

因此，下面的写法有结构性风险：

async function saveLater(db, value) {
  const tx = db.transaction("notes", "readwrite");
  const store = tx.objectStore("notes");
  await prepareRecord(value); // 中文说明：网络或计算会让控制权回到事件循环
  store.put(value);           // 中文说明：此时 tx 可能已经 inactive
}

问题不是一定每次都复现，而是代码把正确性押在浏览器调度细节上。开发环境偶尔成功，切换浏览器、增加一次真实网络等待或让事务先完成后，错误就会暴露。

同一事务内怎样连续完成读写

如果后一个请求依赖前一个请求的结果，把后续数据库调用放进前一个请求的 onsuccess 回调。该回调仍处于事务的活动窗口，可以安全地继续发请求。不要在回调里再用 await 等待无关工作；需要异步准备的数据应提前得到。

function updateTitle(db, id, title) {
  return new Promise((resolve, reject) => {
    const tx = db.transaction("notes", "readwrite");
    const store = tx.objectStore("notes");
    const read = store.get(id);

    read.onerror = () => reject(read.error); // 中文说明：先把请求错误传给调用方
    read.onsuccess = () => {
      const note = read.result;
      if (!note) {
        tx.abort(); // 中文说明：找不到记录时主动回滚当前事务
        return;
      }
      note.title = title;
      store.put(note); // 中文说明：在请求事件回调的 active 窗口继续写入
    };

    tx.oncomplete = () => resolve(); // 中文说明：以事务提交完成作为成功标准
    tx.onabort = () => reject(tx.error || new Error("事务已回滚"));
  });
}

这里的顺序是“读请求完成—修改对象—写请求入队—事务提交”。read.onsuccess 中不需要手动调用 commit()；所有请求完成且没有新请求时，事务会自动提交。

把异步准备和事务写入拆开

更适合生产代码的方式是先准备完整数据，再打开短事务。准备阶段可以请求接口、解析文件或计算摘要；事务阶段只做数据库请求，不承担不可预测的等待。这样既绕开 await 的生命周期问题，也缩短了 readwrite 对对象存储的占用时间。

async function createNote(db, input) {
  const record = await prepareRecord(input); // 中文说明：先完成网络、校验和序列化

  return new Promise((resolve, reject) => {
    const tx = db.transaction("notes", "readwrite");
    tx.objectStore("notes").add(record); // 中文说明：事务内只执行必要的写请求
    tx.oncomplete = () => resolve(record.id);
    tx.onabort = () => reject(tx.error || new Error("写入失败"));
  });
}

async function prepareRecord(input) {
  // 中文说明：示例用微任务模拟准备过程，真实项目可替换为 fetch 或文件解析
  return { id: crypto.randomUUID(), title: String(input.title).trim() };
}

如果必须先读库再决定是否写库，优先把判断和写入安排在同一个请求链的事件回调中；如果判断依赖外部异步结果，则结束第一次事务，等待结果，再新建第二个事务。两个事务之间要接受并发变化，不能把它们假设成一个不可分割的原子操作。

发布前检查事务边界和最终结果

排查这类问题时，不要只看某个请求的 onsuccess。请求成功只代表该请求产生了结果，后续请求仍可能失败，或者事务在提交阶段因为配额、约束、磁盘 I/O 等原因 abort。生产代码至少记录事务级结果，并把失败交给上层重试或提示。

还要避免在 unload 或页面关闭通知里临时创建事务。IndexedDB 请求本身是异步的，页面生命周期结束可能让它来不及完成。需要保存用户操作时，应在操作发生时写入，并在界面上根据 complete 更新保存状态。

相关问题

await Promise.resolve() 也一定会让事务失效吗？

不要把它当成可靠技巧。规范关注的是事务所在的任务和事件回调边界，代码不应依赖某个 Promise 恰好足够快。需要稳定性时，始终把数据库请求放在同一活动窗口内。

能不能用 transaction.commit() 修复跨 await？

不能。commit() 是在 active 事务上提前启动提交，不能让已经 inactive 的事务重新接受请求；在错误位置调用还可能抛出 InvalidStateError。

request.onsuccess 成功了，为什么页面仍提示保存失败？

因为事务可能在后续请求或提交阶段 abort。将最终提示绑定到 transaction.oncomplete，并在 onabort 中保留可诊断的错误信息。

拆成两个事务会不会失去原子性？

会。若两个动作必须一起成功，就把必要请求放进一个事务，并避免中间 await；若外部异步结果无法提前获得，就要设计补偿、状态字段或幂等重试，而不是强行延长旧事务。