indexeddb内存压力主因是二进制数据不当处理而非数据库文件大小；应避免同步加载blob、及时revoke对象url、大图解码移至web worker，并用流式读取与内存缓存控制开销。

IndexedDB 本身不直接占用大量 JavaScript 堆内存，但不当使用二进制数据、未释放引用或滥用解析操作，会引发显著内存压力甚至主线程卡顿。真正影响内存开销的，不是数据库文件大小，而是前端代码如何加载、持有和处理数据。

二进制数据是内存开销主因

IndexedDB 支持 Blob、ArrayBuffer 等原生二进制类型，但存取过程若缺乏控制，极易导致内存暴涨：

• 调用 Blob.arrayBuffer() 会将整个二进制内容同步加载进内存——一张 5MB 图片会立刻占满 5MB 堆空间
• 用 URL.createObjectURL(blob) 创建对象 URL 后未及时 revokeObjectURL，会导致浏览器无法释放底层 Blob 引用，长期驻留内存
• 在主线程中直接解码大图（如 createImageBitmap(blob)）会阻塞渲染，且解码后图像纹理仍驻留 GPU/内存

轻量二进制数据可放心存入

并非所有二进制都不能进 IndexedDB，关键看体积与访问模式：

• ≤200px 缩略图（5–50KB）、白板快照、轻量图标、AI 生成的低分辨率预览图，适合直接存储——它们体积小、读取频次高、与结构化元数据强绑定
• 单个文件超过 2–5MB，或总二进制体积持续增长，应降级：用 Cache API 存 CDN 地址、FileSystem API 落盘、或本地服务器代理 + IndexedDB 只存路径与哈希
• IndexedDB 应专注元数据（id、name、size、updated_at、hash），而非充当“大文件保险柜”

读写阶段的内存节流技巧

避免一次性加载、解析、渲染，改用流式与异步策略：

• 读取大 Blob 时，优先用 blob.stream().getReader() 分块读取，配合 read() 循环处理，不全量载入内存
• 解码类操作（如 image bitmap、PDF 解析）移至 Web Worker，防止主线程冻结
• 对高频访问的缩略图启用内存缓存（Map<string blob></string>），但必须设 TTL 或 LRU 驱逐，避免无限累积
• 事务中只做存储/查询，不做耗时计算；put 前先序列化检查，避免意外存入函数、DOM 节点等不可存对象

监控与主动清理机制

内存问题往往滞后暴露，需建立可观测防线：

• 定期调用 navigator.storage.estimate() 获取当前用量，当 >80% 配额时触发分级清理（先删临时队列，再删过期缓存）
• 为每条记录添加 expiresAt 字段，用游标遍历并删除过期项，避免全量扫描
• 监听 storage 事件或页面卸载前执行 URL.revokeObjectURL 批量清理
• 敏感数据（token、PII）绝不明文存入；必须存时，用 Web Crypto 加密后再写入