indexeddb适合存储小体积、高访问频次、强绑定结构化逻辑的二进制数据，如≤200px缩略图（5–50kb）、白板快照、轻量图标、ai预览图；超2–5mb应降级至filesystem api、cache api、本地服务器代理或服务端对象存储。
IndexedDB 支持直接存储 Blob、File 和 ArrayBuffer 等二进制类型，但不建议直接存大量原始二进制数据（如高清图、视频片段）。真正高效的做法是分离存储策略：结构化元数据走 IndexedDB，大体积二进制内容交由更合适的机制托管。
哪些二进制数据适合存进 IndexedDB？
适合存入的二进制数据需满足两个条件：体积小、访问频次高、与结构化逻辑强绑定。例如：
- 缩略图 Blob（宽度 ≤ 200px，大小通常在 5–50KB）
- 用户绘制白板的导出快照（tldraw 的 JSON + 小尺寸 canvas 导出图）
- 笔记中内嵌的轻量图标或签名图片（base64 解码后的 Blob）
- AI 工具生成的参数预览图（低分辨率、带哈希标识的 thumbnail）
如何避免内存泄漏和主线程阻塞？
读取二进制数据时若不加控制，容易触发内存暴涨或解析卡顿。关键操作要点：
- 用
transaction.objectStore('store').get(key)获取 Blob 后，立即释放引用：处理完立刻调用URL.revokeObjectURL(url) - 避免在 UI 渲染中直接使用
Blob.arrayBuffer()—— 它会将整个二进制加载进内存；改用stream().getReader()分块读取（适用于 >1MB 的 Blob） - 不在 IndexedDB 事务中做耗时解码（如
createImageBitmap(blob)），应移至 Web Worker 或使用await createImageBitmap(blob)异步调用 - 对频繁读取的缩略图启用内存缓存（如 Map
），但设置 TTL 或 LRU 驱逐策略，防止长期驻留
大型二进制数据该存在哪？
当单个文件超过 2–5MB，或总二进制体积持续增长时，应主动降级存储路径：
- FileSystem API（仅 Chromium）：适合离线富媒体编辑器，支持目录结构和流式写入，但兼容性有限
- Cache API + service worker：适合已知 URL 的静态资源（如用户上传后生成的 CDN 地址），可配合 ETag 实现强缓存
- IndexedDB 存元数据 + 本地服务器代理：Revezone 这类桌面增强型应用可通过 Tauri/Electron 暴露本地 HTTP 接口，二进制文件落地磁盘，IndexedDB 只存路径、尺寸、修改时间、校验 hash
- 服务端对象存储（如 S3/MinIO）+ 前端 token 管理：最通用方案，前端只存访问凭证和临时 URL，规避浏览器存储上限与 GC 压力
写入阶段的关键优化
向 IndexedDB 写入二进制前，务必做前置裁剪与格式归一：
- 图片统一转为 WebP（比 PNG 小 25–35%，比 JPEG 更好支持透明通道）
- 限制最大宽高（如强制缩放到 1280×720 内），避免用户误传 4K 截图导致写入失败或超时
- 对重复内容计算 SHA-256 或 xxHash，在写入前查重——相同 blob 可复用已有 key，减少冗余
- 批量写入多个 blob 时，必须包裹在同一个
readwrite事务中，避免每个请求单独开事务带来的开销倍增
