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>），但必须设 TTL 或 LRU 驱逐，避免无限累积 - 事务中只做存储/查询，不做耗时计算；put 前先序列化检查，避免意外存入函数、DOM 节点等不可存对象
监控与主动清理机制
内存问题往往滞后暴露，需建立可观测防线：
- 定期调用
navigator.storage.estimate()获取当前用量，当 >80% 配额时触发分级清理（先删临时队列，再删过期缓存） - 为每条记录添加
expiresAt字段，用游标遍历并删除过期项，避免全量扫描 - 监听
storage事件或页面卸载前执行URL.revokeObjectURL批量清理 - 敏感数据（token、PII）绝不明文存入；必须存时，用 Web Crypto 加密后再写入
