在Chrome扩展中处理大量结构化数据时，IndexedDB几乎是唯一可靠的本地存储方案。但不少人把写入慢归咎于IndexedDB本身，其实真正拖慢速度的往往是事件监听器管理不当。本文不讨论数据库选型，而是聚焦写入路径上的回调控制。

事件监听器如何拖慢写入

IndexedDB的每一次put或add都会返回一个IDBRequest对象。许多开发者习惯给每个请求都挂上onsuccess和onerror，甚至在循环里写匿名函数。这样做看似没毛病，实际上每次回调都会创建一个新的闭包、一次事件派发、一次作用域查找。当一次写入几千条数据时，这些看似微小的开销会被放大。

更隐蔽的问题是事务的生命周期。一个事务内连续发起多个put请求，如果每个请求都单独监听onsuccess，那么事件回调会穿插在事务内部，触发顺序并不完全等同于代码书写顺序。监听器过多还会增加垃圾回收压力，并且一旦某个监听器里抛出异常，可能中断后续请求的派发。精确控制意味着把关注点从事务内单个请求转移到整个事务的完成事件上。

Chrome扩展的Manifest V3使用Service Worker，Service Worker在空闲时会被终止。如果在写入过程中注册了大量未清理的事件监听器，或者把回调挂在全局对象上，会延长内存占用时间，甚至影响下一次唤醒时的执行效率。因此控制监听器不仅是性能问题，也关系到扩展后台的稳定性。

用事务级监听替代请求级监听

IndexedDB提供了两层事件模型：IDBRequest上的onsuccess和onerror，以及IDBTransaction上的oncomplete、onerror和onabort。对于批量写入，真正需要关注的完成时机是transaction.oncomplete，而不是每一个request.onsuccess。把判断逻辑放到事务完成回调里，可以大幅减少监听器数量。

const db = await openDB();
const tx = db.transaction('records', 'readwrite');
const store = tx.objectStore('records');
for (let i = 0; i < 1000; i++) {
  store.put({ id: i, value: 'data_' + i });
}
tx.oncomplete = () => {
  console.log('1000条数据已全部写入');
};
tx.onerror = (e) => {
  console.error('批量写入失败', e.target.error);
};

上面这段代码只在事务上挂载了两个监听器，循环内的put没有单独处理成功事件。事务完成后会拿到单个回调，此时可以安全地通知界面或继续后续流程。对于逐条确认写入结果的需求，可以改为在事务结束后统一校验，而不是在请求级回调里做。

如果业务确实需要在每条数据写入后做针对性处理，可以考虑把记录暂存到内存数组，等到事务完成后统一遍历处理。这样既保留了逻辑完整性，又不会产生上千个事件回调。尤其在Chrome扩展中，数据写入通常伴随着UI更新或消息通知，把这些副作用集中到事务完成时机，可以避免高频触发Service Worker事件。

封装Promise并清理回调

将事务封装成Promise是常见的优化手段。Promise让异步流程更可控，但封装时容易忽略对oncomplete和onerror的清理。正确做法是在resolve或reject后手动解除引用，防止遗留闭包。以下是一个可复用的批量写入函数。

function bulkPut(db, items) {
  return new Promise((resolve, reject) => {
    const tx = db.transaction('records', 'readwrite');
    const store = tx.objectStore('records');
    items.forEach(item => store.put(item));
    tx.oncomplete = () => {
      tx.oncomplete = null;
      tx.onerror = null;
      resolve({ count: items.length });
    };
    tx.onerror = (event) => {
      tx.oncomplete = null;
      tx.onerror = null;
      reject(event.target.error);
    };
  });
}

这里没有给每个put请求设置onsuccess。Promise只关心事务的最终状态，完成或失败后立即移除监听器。注意request.put返回的IDBRequest对象如果不再需要，也不应该保留引用。对于某些旧版浏览器，将request置为null有助于更快释放内存。

另一个常见误区是循环中重复创建事务。比如每写一条数据就调一次db.transaction，这样会生成数百个事务，每个事务都有完整的事件机制和提交开销。应该尽量把相邻写入合并到同一个事务。IndexedDB的事务本身有一定开销，单事务多写入的吞吐量通常远高于多事务单写入。

对比测速与Chrome扩展特别注意事项

用简单的控制台测试可以直观看到差异。在同样的数据量下，单事务批量写入并且只在事务上挂监听器，通常比每个请求都设置onsuccess快数倍。原因不仅在于回调减少，还因为事务内部可以连续排队操作，中间没有JS事件循环反复切换带来的延迟。

在Chrome扩展环境中还需要注意两点。第一，Service Worker的全局作用域内不要保存数据库连接或事务的强引用，否则可能导致Worker无法及时回收。应该按需打开数据库，写入完成后关闭连接。第二，如果写入过程较慢，而扩展的其他事件触发，Service Worker可能会被系统视为空闲而终止。把写入逻辑放在一个Promise中，并配合chrome.runtime或event.waitUntil并不能直接延长Service Worker生命周期，但IndexedDB事务会阻止Worker立即终止，直到事务结束，因此精简监听器可以减少Worker被占用的时间。

另外，使用IndexedDB的try/catch并不等于捕获异步错误。只有在事务的onerror或请求的onerror里才能拿到真实失败原因。如果只依赖try/catch包裹put调用，异步错误会被吞掉。精确控制事件监听器也意味着把错误处理放在正确的位置，而不是到处撒网。