IndexedDB store.add操作内存泄漏问题排查求助

针对你在Firefox中测试写入100个含500个大文本问题的quiz对象时遇到的内存泄漏和峰值过高问题，我来拆解下核心原因和可行的优化方案：

一、内存泄漏的核心原因 #

你提到的不执行delete port.quiz[code[c]]就会导致内存持续增长至2GB且不释放，本质是全局引用未被及时清理：

• 全局数组port.quiz[]持有所有待写入的quiz对象引用，递归调用store_data时，每个未完成的IndexedDB请求（request）内部也会暂时持有要写入的对象副本（用于序列化和写入磁盘）。
• 如果不删除数组中的对应元素，这些对象会同时被全局数组和pending的请求双重引用，垃圾回收器（GC）无法标记回收它们；即使事务结束，全局数组的引用依然存在，内存自然不会释放。
• 添加delete语句后，每次写入成功就释放了数组中的引用，GC可以阶段性回收已写入完成的对象，所以内存会回落；但因为递归是连续发起的，新的对象又进入处理流程，加上GC不是实时触发的，所以峰值会逐步累积，直到所有写入完成、所有引用都被清理后，内存才会恢复初始状态。

二、内存峰值过高的原因 #

即使添加了delete，内存峰值仍居高不下，主要和以下两点有关：

1. 递归串行写入的累积效应：每次等前一个请求成功才发起下一个写入，虽然串行避免了并发写入的冲突，但已处理的对象可能还在GC的待回收队列中，新的对象又进入内存，导致内存占用叠加。
2. Firefox IndexedDB的临时缓存：处理大文本对象时，浏览器会先将对象序列化为内部格式（比如字符串转成UTF-8字节流），这些临时数据会暂存在内存中，直到写入磁盘完成才会被清理；大对象的序列化缓存本身就会占用大量内存，连续写入时这些缓存会累积。

三、具体优化方案 #

1. 改用批量事务写入替代递归串行 #

IndexedDB支持在单个事务中执行多个put操作，不用逐个等待成功再发起下一个。这样可以减少请求数量，降低递归调用栈的压力，同时让GC有机会在批量写入完成后一次性回收一批对象的引用：

// 示例：批量处理，每次写入10个quiz
function batchStoreData(startIndex, batchSize) {
  const db = ...; // 你的数据库实例
  const transaction = db.transaction('quizzes', 'readwrite');
  const store = transaction.objectStore('quizzes');
  
  const endIndex = Math.min(startIndex + batchSize, port.quiz.length);
  for (let i = startIndex; i < endIndex; i++) {
    store.put(port.quiz[i]);
  }
  
  transaction.oncomplete = () => {
    // 清理当前批次的引用
    port.quiz.splice(startIndex, batchSize);
    if (port.quiz.length > 0) {
      batchStoreData(0, batchSize); // 继续处理下一批
    } else {
      console.log('所有写入完成');
    }
  };
  
  transaction.onerror = (e) => {
    console.error('批量写入失败:', e);
  };
}

// 启动批量写入，每次处理10个
batchStoreData(0, 10);

2. 避免全局数组的长期持有 #

不要让port.quiz长期持有所有对象的引用，而是分批取出处理：比如用splice直接移除已处理的批次，而不是逐个delete，这样能更快切断全局引用，让GC及时回收。

3. 优化大文本对象的存储方式 #

如果每个quiz的大文本问题体积很大，可以考虑拆分存储：

• 将quiz的基础信息（如ID、标题）和问题列表分开存储到两个对象仓库中，用外键关联。
• 把大文本转换成Blob或ArrayBuffer存储，IndexedDB处理二进制数据的内存效率比纯字符串更高，且序列化时的临时缓存更小。

4. 控制并发写入的数量 #

如果批量写入的批次太大，也可能导致内存峰值过高，可以尝试调整批次大小（比如从10改成5），找到内存占用和写入速度的平衡点。

5. 手动触发GC（仅调试用） #

在Firefox中可以开启javascript.options.exposeGC（在about:config中设置），然后在批量写入完成后调用window.gc()强制触发垃圾回收，观察内存变化，帮助验证优化效果，但生产环境不建议依赖这个方法。

内容的提问来源于stack exchange，提问作者Gary