IndexedDB事务生命周期内完成读写操作的结构

IndexedDB 的写入偶尔报 TransactionInactiveError，通常不是 put() 本身失效，而是事务已经跨过了事件循环边界。事务创建后若没有继续提交请求，浏览器会把它置为 inactive；没有待处理请求时还可能自动提交。可靠的结构是：先完成网络请求和数据整理，再开启一个短的 readwrite 事务，把连续的读写请求放在同一轮任务或请求成功回调中，最后以 complete 判断真正提交成功。

先准备数据，后开启事务；事务内部只做 IndexedDB 请求，不把 fetch()、定时器或用户交互等待塞进事务生命周期。

先定位：事务为什么突然失活

IndexedDB 事务不是一个可以跨任意异步代码长期持有的连接。创建事务的脚本任务结束后，它会进入 inactive；每个请求的 success 或 error 事件回调执行期间又会暂时变为 active。回调返回且没有新请求时，事务就可能继续结束。

典型故障是先开启事务，再等待外部数据：

async function saveProfile(db, id) {
  // 事务只负责数据库请求，不负责等待网络。
  const tx = db.transaction("profiles", "readwrite");
  const store = tx.objectStore("profiles");
  const profile = await fetch("/api/profile/" + id).then((r) => r.json());
  // await 让控制权回到事件循环，此处可能已经失去 active 状态。
  store.put(profile);
}

这里的 fetch() 返回前，事务没有新的 IndexedDB 请求可继续排队。等 Promise 恢复时再调用 put()，就可能得到 inactive 异常。即使某次浏览器表现得“刚好能写”，也不应把它当作稳定契约。

正确结构：先准备数据，再开启短事务

把网络、表单校验或复杂对象整理放在事务之前。事务内部只读取已经准备好的值，并集中登记成功、失败和最终提交结果。

async function saveProfile(db, id) {
  // 先完成事务之外的异步工作，避免占用事务生命周期。
  const response = await fetch("/api/profile/" + id);
  if (!response.ok) throw new Error("profile request failed");
  const profile = await response.json();

  await new Promise((resolve, reject) => {
    // 事务范围只覆盖真正需要写入的 object store。
    const tx = db.transaction("profiles", "readwrite");
    tx.oncomplete = resolve; // complete 才代表事务整体提交完成。
    tx.onabort = () => reject(tx.error || new Error("transaction aborted"));
    tx.onerror = () => reject(tx.error || new Error("transaction failed"));
    tx.objectStore("profiles").put(profile);
  });
}

这段结构的关键不是把代码写成 Promise，而是让事务创建后立即产生数据库请求。put() 请求成功只说明该请求处理完成，不能替代事务级的 complete；如果多个写入中有一个触发约束错误，最终应以 abort 处理整体回滚。

请求成功回调内如何继续读写

当后一个操作依赖前一个 IndexedDB 请求的结果，可以在前一个请求的 onsuccess 回调里继续发起请求。此时事务仍处于可继续工作的事件回调阶段。

function moveDraft(db, draftId, userId) {
  return new Promise((resolve, reject) => {
    // 两个 object store 都纳入同一个读写事务，保证移动的原子性。
    const tx = db.transaction(["drafts", "published"], "readwrite");
    const draftRequest = tx.objectStore("drafts").get(draftId);

    draftRequest.onsuccess = () => {
      const draft = draftRequest.result;
      if (!draft) {
        // 取消默认错误冒泡，并主动中止本次事务。
        tx.abort();
        return;
      }
      tx.objectStore("published").put({ ...draft, userId });
      tx.objectStore("drafts").delete(draftId);
    };
    tx.oncomplete = resolve;
    tx.onerror = () => reject(tx.error || new Error("move failed"));
    tx.onabort = () => reject(tx.error || new Error("move aborted"));
  });
}

这里的读、写、删属于一次事务，任一步失败都会让调用方得到失败结果。若只是读取后再根据结果等待网络，应该先结束读取事务，等待网络完成后再新建写入事务；不要把两个阶段强行绑在一起。

排查清单：把生命周期问题变成可复查项

• 事务创建后是否在同一任务中立刻调用了 get()、put() 或其他请求？
• 是否把 fetch、setTimeout、用户点击或长时间计算放进了事务前后边界？
• 是否监听了 complete、error 和 abort，而不是只看单个请求的 onsuccess？
• 读写范围是否只覆盖必要的 object store，避免长事务阻塞其他操作？

如果必须读取数据库后再调用接口，采用“读取事务 → 得到普通数据 → 外部异步处理 → 新建写入事务”的两段式结构。若需要强原子性，则把依赖数据提前准备，或重新设计服务端接口，不能靠延长 IndexedDB 事务来跨越网络等待。

常见问题

为什么 Promise.then 有时也会触发事务失活？

关键不在语法是 await 还是 then，而在回调是否让控制权离开当前事务任务，以及恢复时事务是否仍有待处理请求。把依赖事务的请求放在数据库请求事件回调中更清晰。

需要手动调用 transaction.commit() 吗？

通常不需要。没有新请求且所有请求完成后，事务会自动提交；只有在明确需要尽快进入提交阶段、并且代码已确认没有后续请求时，才考虑使用它。最终结果仍用 complete 和 abort 判断。

记住一句话：外部异步操作负责准备数据，IndexedDB 事务负责短而完整地提交数据。把这条边界写进封装层，偶发的“有时能写、有时报 inactive”就会变成可定位的结构问题。