IndexedDB 本身不会导致内存溢出，关键在于采用流式读取、分片事务（每批50–500条）、边读边写、失败重试与进度追踪，并优化索引策略以提升性能。
处理大数据量导入时，IndexedDB 本身不会直接导致内存溢出，但不当的写入方式（如一次性读取全部数据再批量写入）会让 JavaScript 堆内存迅速耗尽。关键不是 IndexedDB 的限制，而是你如何组织数据流和事务生命周期。核心思路是：流式读取 + 分片事务 + 避免内存驻留全量数据。
分片写入：按批次控制事务大小
IndexedDB 单个事务不宜写入过多记录（建议每批 50–500 条，具体取决于单条数据体积）。过大的事务会延长锁定期、增加失败重试成本，还可能触发浏览器内存回收压力。
- 将原始数据源（如 CSV 字符串、JSON 数组、File 或 ReadableStream）按固定数量切分成块，例如每次处理 100 条
- 每个批次开启独立的 readwrite 事务，写完立即提交，不跨批次复用事务
- 用 await 等待当前事务完成后再处理下一批，避免并发事务堆积（尤其在低性能设备上）
避免内存溢出：边读边写，不缓存全量
不要把整个文件 parse 成一个巨型数组再遍历 —— 这是最常见的内存爆点。应采用“解析即写入”策略：
- 对 CSV：用流式解析器（如 Papa Parse 的
chunk回调），每解析出一批行就立刻写入 IndexedDB - 对 JSON：若为大型数组，可用 JSONStream 或手动按行/逗号分割+状态机解析，避免
JSON.parse()整体加载 - 对 File 对象：用
file.stream().getReader()分块读取文本内容，结合换行符切分记录
事务健壮性：失败重试与进度追踪
大数据导入过程长，需容忍单批次失败，并支持断点续传：
立即学习“Java免费学习笔记（深入）”；
- 为每批写入添加
transaction.onabort和transaction.onerror处理，记录失败批次索引 - 在 IDB 中单独建一张
import_progress表，存入已成功写入的最大序号或时间戳 - 导入前先查进度表，跳过已写入部分，而非从头开始
- 必要时加入简单退避重试（如失败后延迟 100ms 再重试一次）
优化写入性能：关闭不必要的索引 & 使用 keyPath
写入速度瓶颈常来自索引维护。若导入阶段不需即时查询，可临时简化结构：
- 建库时，非必需索引（如多个
index）可延后创建，等数据写完再补建 - 确保 objectStore 设有合适的
keyPath，避免使用自增键 + 手动指定 key，减少 key 生成开销 - 若数据天然有序（如带时间戳），按该字段分片并利用 IDB 的范围查询能力，后续读取更高效
