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，避免拷贝
