在 IndexedDB 中存储二进制大对象 Blob 与 ArrayBuffer

IndexedDB 支持直接存储 Blob 和 ArrayBuffer：Blob 需来自当前上下文且未释放，ArrayBuffer 更适合精细二进制操作；大文件应分片存储并流式读取，避免内存压力。

在 IndexedDB 中存储 Blob 和 ArrayBuffer 是完全可行的，而且是官方推荐的原生方式——不需要转成 base64 或字符串，既省空间又少开销。

直接存 Blob 最简单，但得注意“可克隆性”

现代浏览器（Chrome 80+、Firefox 70+、Safari 15.4+）已支持直接 put Blob 对象到 IndexedDB。但前提是：该 Blob 必须来自当前页面上下文，且未被释放（比如未调用 revokeObjectURL 或页面未跳转）。
关键点在于，IndexedDB 底层依赖结构化克隆算法（structured clone），而原生 Blob 在较新版本中已被纳入可克隆类型列表。不过仍要避开以下情况：

• 不要传 File 对象本身（它是 Blob 的子类，但某些旧环境可能触发克隆失败）；建议先调用 file.slice() 或直接用 file.arrayBuffer()
• 避免在 put 前反复构造新 Blob，如 new Blob([blob]) —— 虽不报错，但会多占内存
• 写入后读出的仍是标准 Blob 实例，可直接传给 URL.createObjectURL() 或 fetch() 发送

ArrayBuffer 更底层，适合精细控制

如果你需要操作二进制内容的某一段（比如解码图片头、加密校验、生成缩略图），ArrayBuffer 是更合适的选择。它本质是一段连续内存，配合 Uint8Array 或 DataView 就能逐字节读写。

• 写入前确保 ArrayBuffer 没被 detach（例如没被 transfer 过，也没被视图长期引用后释放）
• 推荐连同元信息一起存，例如：{ id: 1, data: buffer, type: "image/jpeg", size: buffer.byteLength }
• 读取后得到的是完整副本，可直接 new Uint8Array(result.data) 创建视图，无需额外解析
• 别把 ArrayBuffer 转成字符串再存——体积膨胀、编码耗时，纯属绕路

大文件别硬塞，分片才是稳态方案

单个 Blob 或 ArrayBuffer 超过 200MB 容易触发浏览器内存压力或事务超时。稳妥做法是分片存储：

• 把文件按固定大小（如 2–4MB）切分成多个 ArrayBuffer 片段
• 建两个 objectStore：files 存元数据（文件名、总片数、MIME 类型），file_chunks 存每一片，key 设为 "${fileId}_${index}"
• 查某文件所有分片时，用 IDBKeyRange.bound("abc_0", "abc_99999") 配合 cursor 高效遍历
• 拼接还原时，用 new Blob(chunks) 即可得到完整 Blob，无需手动合并 ArrayBuffer

读取时别全加载进内存

对大图片或视频，直接调 blob.arrayBuffer() 可能导致页面卡死甚至崩溃。应优先利用流式能力：

• 读取记录后，调用 cursor.value.stream() 获取 ReadableStream
• 配合 response.body = stream 直接用于 <img src="blob:..."> 或下载链路
• 若需局部处理（如裁剪首帧），可用 blob.slice(0, 1024*1024) 提取前 1MB，再 createObjectURL(new Blob([chunk]))
• 复杂解析任务（如 EXIF 提取、HEIC 解码）建议扔进 Web Worker，并用 transferable 传递 ArrayBuffer，避免拷贝