IndexedDB批量操作需系统优化：用单事务包裹多条写入、优先选Dexie.js的bulkAdd/bulkPut、大数据集分块处理、前置创建索引。
IndexedDB 批量操作不是简单地“多插几条”，而是围绕事务控制、内存占用、索引利用和连接复用做系统性优化。核心目标是减少事务开销、避免主线程阻塞、防止 OOM，并保持查询响应速度。
用单事务包裹全部写入操作
每次调用 add()、put() 单条写入，都会隐式开启并提交一个事务——这带来显著的调度与 I/O 开销。正确做法是显式创建一个读写事务，把所有操作集中执行：
- 使用
db.transaction(['storeName'], 'readwrite')显式声明事务范围 - 在同一个事务中连续调用
store.add()或store.put()，数量可达数百甚至上千（取决于单条数据大小） - 监听
transaction.oncomplete和transaction.onerror做统一结果处理，而非每条单独监听
优先选用 bulk 方法（尤其搭配 Dexie.js）
原生 IndexedDB 不提供批量接口，但 Dexie.js 封装了高效替代方案，底层仍基于单事务，但 API 更安全、容错更强：
-
bulkAdd(items)：适用于纯新增场景，主键冲突会报错，适合初始化导入 -
bulkPut(items)：支持“存在则更新、不存在则插入”，适合同步状态或增量更新 - 二者均比循环调用
add()快 5–10 倍，且自动处理事务生命周期
分块处理超大数据集（如 >5000 条）
一次性加载全部数据进内存再写入，容易触发内存警告或卡顿。应主动切片，配合异步节奏控制：
- 将数据按 500–1000 条为一组，每组在一个独立事务中提交
- 组间用
await或setTimeout(..., 0)让出主线程，避免页面冻结 - 可结合
requestIdleCallback在浏览器空闲时继续下一批，提升用户体验
写前确保索引就位，避免事后重建
批量写入后若立即按新字段查，而该字段尚未建索引，查询会退化为全表扫描。务必前置规划：
- 在
onupgradeneeded中，随 objectStore 一起创建高频查询字段的索引，例如：store.createIndex('byTag', 'tag') - 避免在已有大量数据后再调用
createIndex——它会同步遍历全量数据，造成长时间阻塞 - 复合索引（如
['status', 'createdAt']）对排序+过滤组合查询效果明显
