indexeddb优化核心是“读得巧、处理得轻、释放得及时”：避免getall()等全量加载，改用游标或分页；写入前精简字段、预计算、加密；事务按100–500条分块；读取后主动清理引用。
IndexedDB 本身是磁盘持久化存储，不直接占用 JS 堆内存，但 JavaScript 层面对它的操作——尤其是读取、遍历、序列化大量数据时——极易引发内存暴涨甚至浏览器崩溃。优化核心不是“存得少”，而是“读得巧、处理得轻、释放得及时”。
避免一次性加载全量数据
这是最常见也最危险的操作。调用 toArray() 或 getAll() 获取数千条记录，会把所有对象完整解包进内存，触发 GC 压力甚至 OOM。
- 改用 each()（Dexie.js）或游标 openCursor()（原生），逐条处理，内存只保留当前项
- 如需分页展示，用 offset() + limit() 控制每次只拉取 50–200 条，配合滚动加载
- 对超大数据集（如日志分析），可结合 requestIdleCallback 在空闲帧中分批读取，不卡 UI
写入前做数据精简与预计算
写进去的数据越“重”，后续读取和反序列化的开销就越大。预处理能从源头减负：
- 剔除非必要字段：编辑草稿中的临时状态、撤销栈、UI 位置信息等，不入库
- 时间戳统一转为毫秒整数，比
Date对象或 ISO 字符串节省约 40% 内存与解析时间 - 高频查询字段提前计算好值并建索引，例如
yearMonth: "202608"，避免查询时反复new Date().getFullYear() - 敏感字段（如 token、邮箱）在写入前用 Web Crypto 加密，避免明文堆叠增加内存压力
控制事务粒度与作用域
大事务虽减少开销，但会锁住 store 并持续占用资源；小事务频繁调度又拖慢整体速度。关键在于平衡：
- 单次写入建议按 100–500 条分块，每块一个独立
readwrite事务 - 事务创建时显式指定 store 名称，如
db.transaction(['logs'], 'readwrite')，避免意外锁定其他 store - 每批写完后用
await queueMicrotask(() => {})让出主线程，比setTimeout(0)更及时，保障动画帧不丢 - 失败时记录最后成功 ID 或时间戳，支持断点续传，不重复加载已处理数据
读取后及时清理引用
JS 引擎不会自动释放你手动持有的大数据引用，尤其在闭包、全局变量或未清空的数组中：
- 用完
toArray()结果后，主动设为null或清空数组，帮助 GC 快速回收 - 避免在事件监听器或定时器中长期持有大批量数据引用
- 使用 WeakMap 缓存关联数据（如 UI 元素 ↔ DB 记录），它不阻止 GC，适合临时映射
- 定期用 Chrome DevTools 的 Memory 面板录制堆快照，确认无意外的“Detached DOM tree”或长生命周期对象滞留
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
