indexeddb大容量读写需主动管理内存：写入要分片（100–200条/批）、设null释放引用；读取禁用getall，改用索引+游标分页；显式切断引用、压缩数据、分库过期淘汰。
IndexedDB 大容量读写时内存缓冲区不释放，本质是浏览器在批量操作中将大量数据暂存在 JS 堆或内部缓存中，未及时 GC 或清空引用。这不是“等它自己回收”的问题，而是必须主动干预的资源管理行为。
写入阶段：拆事务 + 控制游标 + 避免全量加载
单次写入几千条记录，Chrome 会把整个数组保留在内存中直到事务结束；Safari 更敏感，500 条就可能卡住。关键不是“少写”，而是“分片写、早释放”：
- 每批控制在 100–200 条，用
put()替代add()，避免主键冲突中断整批 - 每次事务提交后，手动将已处理的 chunk 数组设为
null，并调用delete chunk显式解除引用 - 不用
getAll()加载原始数据源；若数据来自 JSON 接口，先用JSON.parse(chunkStr)分块解析，解析完立即丢弃原始字符串
读取阶段：禁用 getAll，改用 cursor + index 分页遍历
getAll() 会把全部匹配记录一次性拉进 JS 堆——10 万条中等对象轻松占 200MB+，触发 GC 压力甚至页面崩溃。正确做法是让 IndexedDB 自己按需吐数据：
- 对常用查询字段建索引（如
createIndex('by_time', 'timestamp')），再用index.openCursor(IDBKeyRange.bound(...))精准扫描 - 每次只取 50–100 条，处理完立刻调用
cursor.continue()，不缓存全部结果；用闭包外变量累计处理进度，不保留游标链表 - 读取二进制或大文本字段时，优先用
getAsArrayBuffer()或getText()流式接口（如支持），避免转成完整字符串再操作
内存清理：显式切断引用 + 主动触发轻量 GC 提示
JS 引擎不会因为你“用完了”就立刻回收，尤其涉及大量对象引用时。需人工辅助：
- 事务完成回调里，把所有临时数组、map、result 对象设为
null，并用delete obj.key清除属性级引用 - 对超大对象仓库（如存日志、附件），读写后调用
transaction.abort()显式终止事务，防止浏览器后台维持缓存句柄 - 在长任务间隙插入
setTimeout(() => {}, 0)，让事件循环有机会触发微任务队列清空和部分 GC 回收（非强制，但可提升响应）
长期策略：压缩 + 分库 + 过期淘汰
治本要从数据结构入手，减少原始体积和驻留必要性：
- 长文本、JSON 配置类字段，入库前用
TextEncoder + pako.deflate()压缩，读取时解压；实测节省 60%+ 存储与内存占用 - 按时间切分数据库，例如
log_db_202405、log_db_202406，旧库设为只读，新数据不混入，避免单库膨胀拖慢游标遍历 - 写入前估算体积：
new Blob([JSON.stringify(item)]).size粗略判断单条大小，总量超 20MB 时自动触发归档或截断逻辑
