前端 IndexedDB 事务自动提交前为什么不能异步等待

IndexedDB 的事务不是可以长期挂起的 Promise。事务创建后，浏览器只会在当前任务以及某个请求的 success、error 回调中允许继续发请求；回调结束、没有新的请求时，事务就可能自动提交。因此，在同一个 readwrite 事务里直接 await fetch()，再调用 store.put()，很容易得到 TransactionInactiveError，或者发现后续写入没有进入原来的事务。

为什么 await 会让事务失去活性

db.transaction() 返回的是已经开始的 IDBTransaction，不是等到第一次 get() 才开始。事务处于活动状态时可以创建请求；当当前任务结束、没有待处理请求，或者代码在两个请求之间跨过了一个普通的 Promise 等待，浏览器就可以让它进入非活动状态并提交。

所以问题不在于 IndexedDB “不能异步”，而在于两种异步的边界不同：get()、put() 是由事务管理的数据库请求；await fetch()、await delay() 是普通事件循环任务。后者不会替事务续期。complete 事件只表示提交已经成功，不能拿来恢复一个已经完成的事务。

把连续请求放回同一条 request 回调

读后写的关键不是把所有函数都改成同步，而是让后一个数据库请求由前一个数据库请求的回调触发。下面的示例只在一个 readwrite 事务中完成读取和更新，并用事务事件判断最终结果：

function touchNote(db, id) {
  // 事务范围只包含本次要修改的 notes 对象仓库
  const tx = db.transaction("notes", "readwrite");
  const store = tx.objectStore("notes");
  const readRequest = store.get(id);

  // 在数据库请求回调里继续发出写请求，不跨普通 await
  readRequest.onsuccess = () => {
    const note = readRequest.result || { id, title: "未命名" };
    note.updatedAt = Date.now();
    store.put(note);
  };

  // 请求错误会冒泡到事务，统一处理回滚原因
  readRequest.onerror = () => tx.abort();
  tx.oncomplete = () => console.log("笔记已提交");
  tx.onerror = () => console.error("事务失败", tx.error);
}

这里可以把 await 用在“打开数据库”或“等待事务完成”的外层，但不要把它放在已经创建事务之后，再期待原来的 objectStore 继续可写。多个依赖请求也遵循同一原则：在当前 request 的成功回调中安排下一个 request；如果链条太长，优先拆成几个短事务。

把网络等待和数据库事务拆开

如果保存动作必须先请求接口，推荐让网络阶段和数据库阶段各自拥有明确的生命周期。先拿到可写入的数据，再开一个尽量短的事务：

async function cacheProfile(db, url) {
  // 网络等待发生在事务创建之前，不占用 IndexedDB 事务
  const response = await fetch(url);
  const profile = await response.json();

  await new Promise((resolve, reject) => {
    const tx = db.transaction("profiles", "readwrite");
    // 数据已经准备好，事务内只做一次明确写入
    tx.objectStore("profiles").put(profile);
    tx.oncomplete = resolve;
    tx.onerror = () => reject(tx.error);
    tx.onabort = () => reject(tx.error || new Error("事务已回滚"));
  });
}

反过来，事务完成后再做日志上报、界面刷新或下一次网络请求也更容易排错。不要为了“少写一次打开事务”而把 fetch、用户确认、定时器和数据库写入塞进同一个事务。

版本升级与同源边界如何一起排查

创建对象仓库或索引属于 schema 变更，只能放在打开更高版本触发的 onupgradeneeded 中。普通的 readwrite 事务不能替代版本升级事务。多标签页同时打开数据库时，旧连接未关闭还可能触发 blocked；这不是异步写入失活，而是升级连接协调没有完成。

function openNotes() {
  return new Promise((resolve, reject) => {
    // 提高版本号后，schema 变更只在升级事务中执行
    const request = indexedDB.open("notes-app", 2);
    request.onupgradeneeded = () => {
      const db = request.result;
      if (!db.objectStoreNames.contains("notes")) {
        db.createObjectStore("notes", { keyPath: "id" });
      }
    };
    request.onblocked = () => console.warn("请关闭其他标签页后再升级");
    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
  });
}

最后检查同源：IndexedDB 数据按 origin 隔离，协议、主机名或端口不同，就算数据库名相同也不是同一个数据库。iframe、开发环境端口和生产域名之间的“读不到”，应先核对 origin，再去看事务生命周期。

可继续查阅 MDN 的 IDBTransaction、IndexedDB 使用指南 和 Indexed Database API 规范，重点看 transaction 的 active/inactive 状态和自动提交条件。

相关问题

能不能在事务里直接使用 Promise.all？

只有当所有请求都已经在活动任务中创建，并且不依赖普通 Promise 回调继续追加请求时才稳妥。Promise.all 本身不会延长事务，不能把它当作事务续期工具。

为什么 put 没报错但数据没有更新？

先确认是否观察了正确的数据库和 origin，再检查 tx.oncomplete、tx.onerror 与 tx.onabort。如果 put 实际发生在事务自动提交之后，通常会直接抛出失活异常；如果打开的是另一个 origin，则看起来像“写入成功但读取不到”。

什么时候应该拆成两个事务？

当中间需要网络、用户交互、定时器或较长计算时就拆开。先完成外部异步工作，再用一个短事务提交最终数据，失败时也更容易重试。