IndexedDB 事务自动提交前怎样完成异步读取

IndexedDB 的关键不是把事务对象保存得更久，而是把下一次数据库请求安排在当前事务仍然允许发请求的任务里。创建事务的任务，以及前一个 IDBRequest 的 success/error 回调任务，通常是可以继续使用该事务的活动时机；如果在中间交给网络请求、定时器或其他任务，事务可能已经没有待处理请求并自动提交。

官方资料：https://developer.mozilla.org/en-US/docs/Web/API/IDBTransaction

实用判断：事务内只做短小的数据库请求；需要等待数据库之外的异步结果时，先把数据读出来并让事务结束，外部操作完成后再开启一个新事务写回。

• 连续的 IndexedDB 读取：在前一个请求的 onsuccess 中发起下一个请求。
• 网络、定时器和复杂业务计算：放到事务外，不要依赖旧事务跨越它们。
• 单个请求成功：只代表该请求完成；事务最终是否提交要看 transaction.oncomplete。
• 事务失效：不要用 commit()“保活”，它的作用是推进提交，而不是延长生命周期。

先理解事务为什么会在 await 后失效

IDBTransaction 会在事件循环任务之间切换 active 和 inactive。它在创建事务的任务、以及请求成功或失败事件的处理任务中处于活动状态；如果没有新的请求，且现有请求也已经处理完，浏览器就可以自动提交事务。此时再从旧的 objectStore 发请求，就可能得到事务非活动或事务已完成相关的异常。

因此，下面这种写法的问题不在 await 语法本身，而在它等待的是 IndexedDB 之外的任务：

// 反例：外部异步操作可能让事务先进入非活动状态
async function loadThenWrite(db, id) {
  const transaction = db.transaction("notes", "readwrite");
  const store = transaction.objectStore("notes");
  const note = await requestToPromise(store.get(id));

  // 网络请求不属于当前 IndexedDB 请求队列，等待期间不要继续使用旧事务
  const label = await fetchLabel(note.labelId);
  store.put({ ...note, label }); // 可能抛出事务非活动或已完成异常
}

// 把 IDBRequest 转成 Promise，便于说明请求结果的异步边界
function requestToPromise(request) {
  return new Promise((resolve, reject) => {
    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
  });
}

这段代码的危险点是中间的 fetchLabel。第一个数据库请求已经返回结果，事务又没有新的数据库请求需要等待，浏览器可以让它完成；网络 Promise 结束时，旧事务不再是一个可靠的写入容器。

依赖前一次结果时，在请求回调里继续读取

如果两次读取都属于同一个事务，而且第二次读取依赖第一次的结果，就把第二个请求直接放在第一个请求的成功回调里。回调正是 IndexedDB 给当前事务提供下一次请求机会的地方：

// 依赖读取：第二个请求在第一个请求的 success 回调中加入队列
function readNoteAndAuthor(db, noteId) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction(["notes", "authors"], "readonly");
    const notes = transaction.objectStore("notes");
    const authors = transaction.objectStore("authors");
    let result;

    transaction.onerror = () => {
      // 事务级错误负责兜底，避免只等待某个请求而漏掉回滚
      reject(transaction.error ?? new Error("读取事务失败"));
    };
    transaction.onabort = () => {
      reject(transaction.error ?? new Error("读取事务已中止"));
    };

    const noteRequest = notes.get(noteId);
    noteRequest.onerror = () => reject(noteRequest.error);
    noteRequest.onsuccess = () => {
      const note = noteRequest.result;
      if (!note) {
        resolve(null);
        return;
      }

      // 仍在请求事件回调中，继续使用同一个 readonly 事务
      const authorRequest = authors.get(note.authorId);
      authorRequest.onerror = () => reject(authorRequest.error);
      authorRequest.onsuccess = () => {
        result = { note, author: authorRequest.result ?? null };
        resolve(result);
      };
    };
  });
}

这里的两个 get() 不是同时盲目发出：第二个键依赖第一条记录的 authorId，所以在第一个请求成功时追加。若所有键在开始时都已知，也可以在创建事务后同步发出多个请求，再分别处理结果；关键仍是不要在事务请求之间跨出不受控的外部任务。

request 成功不等于 transaction 已提交

request.onsuccess 只说明这一个请求已经得到结果。读取事务还有自己的完成事件；写入场景尤其要等待 transaction.oncomplete，因为请求成功并不等同于整个事务最终提交成功。

// 等待事务完成，用事务事件表达“整体提交”结果
function waitForTransaction(transaction) {
  return new Promise((resolve, reject) => {
    transaction.oncomplete = () => resolve();
    transaction.onabort = () => reject(transaction.error ?? new Error("事务中止"));
    transaction.onerror = () => {
      // 某些错误会继续冒泡到事务，最终结果仍以 complete/abort 为准
      reject(transaction.error ?? new Error("事务错误"));
    };
  });
}

// 已知键可以在同一个活动任务里一次性排入多个读取请求
function readSettings(db, keys) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction("settings", "readonly");
    const store = transaction.objectStore("settings");
    const requests = keys.map(key => store.get(key));
    const values = [];

    transaction.onerror = () => reject(transaction.error);
    transaction.onabort = () => reject(transaction.error ?? new Error("读取中止"));
    transaction.oncomplete = () => resolve(values);
    requests.forEach((request, index) => {
      request.onsuccess = () => { values[index] = request.result; };
      request.onerror = () => reject(request.error);
    });
  });
}

在这个示例里，Promise 在 oncomplete 中才 resolve，调用方得到的是“事务已经成功完成”的信号，而不是某一个请求的局部结果。错误处理仍应按业务需要补充去重、缺失值和权限等分支。

网络或业务异步操作要拆成两个事务

最稳妥的工程模式是把事务缩短为“读数据”和“写结果”两个阶段。第一阶段只把网络请求所需的普通数据读出来；事务完成后再调用 fetch 或执行外部计算；最后重新打开 readwrite 事务，并在写回前确认记录仍符合业务条件。

// 把外部 await 放在事务之间，而不是放在事务内部
async function refreshNoteLabel(db, noteId) {
  // 第一阶段：只读，完成后不再引用旧 transaction 或旧 objectStore
  const note = await readOneNote(db, noteId);
  if (!note) return { updated: false, reason: "missing" };

  // 第二阶段：网络和业务计算发生在事务外
  const label = await fetchLabel(note.labelId);

  // 第三阶段：新事务写回，并用条件检查避免覆盖新版本
  return writeLabelIfUnchanged(db, noteId, note.revision, label);
}

function writeLabelIfUnchanged(db, noteId, revision, label) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction("notes", "readwrite");
    const store = transaction.objectStore("notes");
    const request = store.get(noteId);

    transaction.onerror = () => reject(transaction.error);
    transaction.onabort = () => reject(transaction.error ?? new Error("写入中止"));
    transaction.oncomplete = () => resolve({ updated: true });

    request.onerror = () => reject(request.error);
    request.onsuccess = () => {
      const current = request.result;
      if (!current || current.revision !== revision) {
        // 版本已变化时主动回滚，避免把旧网络结果覆盖到新记录
        transaction.abort();
        resolve({ updated: false, reason: "conflict" });
        return;
      }
      store.put({ ...current, label, revision: revision + 1 });
    };
  });
}

拆分之后要面对一个新的问题：外部等待期间数据可能被别的标签页或组件修改，所以示例用 revision 做条件检查。这个检查属于业务并发策略，不是 IndexedDB 自动提供的版本控制；如果记录不再是读到的版本，就放弃旧结果或重新计算。

几个看似能解决问题但方向相反的做法

另一个常见误区是把 Promise 包装器当成事务生命周期管理器。Promise 只能改变结果的表达方式，不能改变浏览器何时把事务视为活动；如果包装器内部在回调之间插入了网络、定时器或消息等待，仍然要按任务边界重新设计。

接入前的判断清单

1. 下一次 IndexedDB 请求是否依赖上一次请求的结果？依赖时放进上一次请求的成功回调。
2. 中间是否要等待网络、定时器、用户输入或其他 Promise？有就结束当前事务，再拆新事务。
3. 这是只读还是写入？写入不仅要处理请求错误，还要以事务完成或中止作为整体结果。
4. 外部异步完成后，数据库记录是否可能已变化？需要 revision、时间戳或其他条件写策略。
5. 清理时是否会继续引用旧事务？组件卸载、页面切换或请求取消时，应让迟到结果不能写回旧状态。

IndexedDB 的异步读取并不要求把一个事务拉得很长。把数据库请求组织成短链，在请求事件回调里继续排队；把数据库之外的等待明确放在事务两侧，通常就能避开“await 后事务突然不能用了”的问题。

为什么 request.onsuccess 后还要等 transaction.oncomplete？

请求成功只表示单个操作返回结果，事务可能还有其他请求，也可能因后续错误而中止。要把写入视为整体成功，应等待事务的 complete 事件。

所有 IndexedDB 读取都必须写成回调吗？

可以用 Promise 包装请求改善调用形式，但不能用包装器掩盖事务的事件循环边界。连续读取要让下一次请求发生在合法的请求事件回调或同一活动任务中。

能不能用 transaction.commit() 防止自动提交？

不能。commit() 会启动提交过程，且只能对活动事务调用；它不是保活 API。要等待外部异步操作，应把操作移到事务外。

网络结果回来后怎样避免覆盖别人的修改？

重新开启写事务，在事务内读取当前记录并比较 revision 或其他条件；不匹配时中止本次写回、提示冲突或重新计算。