IndexedDB性能瓶颈源于事务粒度、索引冗余、序列化开销及内存压力，而非磁盘碎片；应批量事务（50–200条/批）、精简索引、预压缩数据并实测监控。
大量数据写入浏览器存储时，性能开销主要来自事务管理、序列化、索引更新和内存压力，而非磁盘碎片——IndexedDB 本身不暴露底层存储碎片状态，也无需手动整理。
事务粒度决定写入效率
每次 add() 或 put() 单独发起事务，会触发完整生命周期（开启→写入→索引更新→提交→清理），带来显著开销。尤其在批量导入场景中，1000 条记录分 1000 次事务，比单事务写入慢数倍。
- 始终用一个
readwrite事务包裹整批数据，例如：db.transaction(['items'], 'readwrite') - 每批控制在 50–200 条之间，避免事务过大导致长时间阻塞主线程或触发浏览器内存回收
- 对超大批量（如 10 万+条），采用分片 +
setTimeout或requestIdleCallback逐步提交，保持界面可响应
索引是双刃剑：建得少，查得快
每个索引都会在写入时同步更新，字段越长、选择性越低，写入膨胀越明显。例如为 2KB 的 description 字段建索引，不仅拖慢插入，还大幅增加数据库体积。
- 只对实际用于
openCursor(index)或index.get()的字段建索引 - 复合索引按高频查询顺序排列，如常查
category = 'news' AND timestamp > X，就建[category, timestamp] - 删除长期不用的索引，可通过
objectStore.deleteIndex('old_index')在 upgrade 事务中移除
内存与序列化开销不可忽视
IndexedDB 写入前需将 JS 对象序列化为结构化克隆，大对象（如含 ArrayBuffer、嵌套深的 JSON）会显著拉高 CPU 和内存占用；读取后反序列化同样耗资源。
- 写入前精简数据：剔除 UI 渲染无关字段、压缩长文本（如用 LZUTF8 预压缩再存）
- 避免直接存 DOM 节点、函数、undefined 等无法克隆的值
- 监控内存增长：用
performance.memory（若可用）或 Chrome DevTools 的 Memory 面板观察写入前后变化
日志与监控能定位真实瓶颈
所谓“变慢”往往不是存储本身，而是误用模式。靠直觉判断不如实测关键路径耗时。
- 在事务
oncomplete中打点，对比单条 vs 批量、有索引 vs 无索引的耗时差异 - 用 Chrome 的 Performance 面板录制操作，查看
indexedDB相关任务是否出现长任务（>50ms） - 留意控制台警告，如 “Blocked by large transaction” 或 “QuotaExceededError”，它们指向容量或设计问题，而非碎片
