indexeddb批量插入的关键是单事务内完成所有写入。需显式开启readwrite事务，复用objectstore实例，分块处理（200–500条/块），避免并发事务和无效监听，并通过performance面板定位真实瓶颈。

IndexedDB 批量插入的核心不是“一次塞很多条”，而是“在一个事务里完成所有写入”。事务是原子性的唯一保障，也是性能差异的分水岭。

批量插入必须用单事务封装

逐条调用 add() 但不复用事务，本质上仍是串行提交——每条数据都触发独立的写入流程、索引更新和内部日志记录，性能接近最差情况。真正有效的批量，是显式开启一个 readwrite 事务，再把全部 add() 或 put() 请求挂载到它上面。

• 用 db.transaction([storeName], 'readwrite') 获取事务实例，不要在循环里反复创建
• 所有数据写入操作必须基于该事务的 objectStore 实例发起
• 监听 oncomplete 和 onabort 统一收口，避免遗漏失败处理

大数据量需主动分块（chunk）

单事务塞入几万条数据容易触发浏览器内存警戒或事务超时，尤其在低端设备上。实测表明，200–500 条/事务是较稳妥的平衡点：既大幅减少事务开销，又避开阻塞主线程或 OOM 风险。

• 将原始数据数组按固定大小切片，例如 Array.from({ length: Math.ceil(dataList.length / 200) }, (_, i) => dataList.slice(i * 200, (i + 1) * 200))
• 顺序执行每个分块的事务（避免 Promise.all 并发多个事务——它们彼此不具原子性）
• 可加简单节流，如每轮后 await new Promise(r => setTimeout(r, 0)) 让出微任务队列，防界面卡死

压测时关注真实瓶颈指标

别只看总耗时。打开 Chrome DevTools 的 Performance 面板录制操作，重点观察：

• IndexDB operation 时间占比：若过高，说明事务设计不合理或索引过多
• Scripting 占比突增：可能是数据预处理（如格式转换、去重）拖慢了，而非 IndexedDB 本身
• Memory 曲线是否陡升：未及时释放中间数组或游标引用，易引发 GC 停顿
• 对比开启/关闭索引后的写入速度：每个索引都会在写入时同步更新，高频写场景建议上线前精简非必要索引

避免常见陷阱

很多“优化”反而拖慢速度：

• 在事务内反复调用 objectStore() 获取 store 实例——应复用一次获取的结果
• 为每条数据单独监听 add().onsuccess ——这会打断事务聚合，且无实际收益
• 误用 localStorage 模拟批量：它没有事务、不能结构化存储、容量小、同步阻塞 UI，完全不适合压测对比
• 忽略版本升级逻辑：首次建库或新增索引必须在 onupgradeneeded 中完成，否则后续写入会失败