indexeddb 不能直接存储 blob 对象，因其不支持结构化克隆，需转为 arraybuffer 或 uint8array；推荐分离元数据与二进制数据、分块写入、及时 revoke objecturl 并处理事务异常。
IndexedDB 存储图片 Blob 时为什么不能直接存 blob 对象？
因为 IndexedDB 只支持结构化克隆（structured clone），而原生 Blob 对象不可克隆——直接 put 会报 DataCloneError: An object could not be cloned。必须先转成可存储的格式，最常用的是 ArrayBuffer 或 Uint8Array。
实操建议：
- 用
blob.arrayBuffer()获取二进制数据（现代浏览器已广泛支持，无需 FileReader） - 避免用
URL.createObjectURL(blob)后存字符串路径——这不离线，且 URL 会在页面卸载后失效 - 如果图片来自
fetch响应，优先用response.arrayBuffer()直接获取，跳过 Blob 构造环节，减少内存拷贝
如何设计适合图片存储的 IndexedDB Schema？
单图体积大、数量多，Schema 设计直接影响读写性能和事务稳定性。别用一个 objectStore 存所有字段，尤其别把二进制塞进索引字段里。
推荐结构：
- 主 objectStore 名为
images，keyPath 用自增id或业务唯一 ID（如urlHash） - 只存必要元数据：
url、mimeType、width、height、size（字节数）、createdAt - 二进制数据单独存在另一个 objectStore
imageBlobs，用外键imageId关联；这样读元数据快，按需加载二进制，也利于分片清理 - 加一个
url索引（unique: false），方便重复 URL 去重或覆盖更新
从 IndexedDB 读取并渲染图片时，如何避免 DOMException: Failed to execute 'createObjectURL' on 'URL'？
这个错误通常是因为你试图对已释放或无效的 ArrayBuffer 调用 URL.createObjectURL(new Blob([buffer], {type: mimeType}))。IndexedDB 返回的数据是“活”的 ArrayBuffer，但一旦事务关闭，其底层引用可能被 GC 回收（尤其在 Chrome 中）。
安全做法：
- 读取后立刻构造
Blob，不要跨事务保存ArrayBuffer引用 - 用
new Blob([arrayBuffer], {type: mimeType})显式传入类型，别依赖blob.type（它在 ArrayBuffer 构造时不自动推断） - 渲染完记得调用
URL.revokeObjectURL(url)，否则内存泄漏；可在img.onload或img.onerror后立即 revoke，或用AbortController配合 cleanup - 若频繁渲染同一批图片，可加一层内存缓存（Map
存 url → objectUrl），但需配合 LRU 和显式清理逻辑
海量图片下，事务失败、QuotaExceededError 或卡顿怎么处理？
IndexedDB 没有全局配额提示，单次写入超 50MB 就容易触发 QuotaExceededError；长时间事务还会阻塞 UI，尤其在低配安卓设备上。
应对策略：
- 写入分块：每批 ≤ 10 张图，每张图单独事务或小批量 commit，用
Promise.allSettled控制并发（建议 3–5 并发） - 监听
indexedDB.onupgradeneeded和db.onabort，失败时记录event.target.error?.name，区分QuotaExceededError和TransactionInactiveError - 对超大图（>2MB）做预处理：前端用
createImageBitmap+canvas.toBlob压缩降质再存，减小体积和写入压力 - 初始化 DB 时显式请求更大空间（仅 Chrome 支持）：
navigator.storage?.estimate().then(est => console.log('quota:', est.quota))，但不能强制分配
真正麻烦的不是存不下，而是用户切走又切回时事务中断、Blob 构造时机错乱、objectURL 泄漏堆积——这些细节比 schema 设计更影响长期可用性。
