优先indexeddb存结构化数据（如用户表、订单），opfs存大文件（如视频、cad模型）；混合使用更常见，即indexeddb管元数据、opfs存原始文件，兼顾查询效率与文件操作稳定性。
选 IndexedDB 还是 OPFS，关键看你在存“数据”还是在存“文件”。不是谁更新、谁更快的简单对比，而是工作流是否匹配底层能力。
存结构化业务数据（如用户表、订单记录、配置项）→ 优先 IndexedDB
IndexedDB 是为结构化数据设计的 NoSQL 数据库。它支持索引、事务、查询条件过滤、批量增删改，天然适配关系型思维的数据操作。
- 适合场景：用户资料同步、离线表单缓存、本地消息队列、带条件搜索的本地日志
- 优势明显：写入后可立即按字段查（比如
where status = 'pending'），事务保证多条记录一致性，错误恢复机制成熟 - 注意点：存 Blob（如小图标、缩略图）可以，但不建议频繁读写百 MB 级 Blob；序列化/反序列化开销随体积增大而显著
存大文件或流式写入（如录屏、音视频剪辑、CAD 模型、导出 ZIP）→ 直接上 OPFS
OPFS 不是数据库，是浏览器里的私有文件系统。它没有“记录”概念，只有文件和目录，支持 createSyncAccessHandle、分块写入、随机读取、文件锁等原生语义。
- 适合场景：录制中边产边存、大文件分片上传前缓存、本地视频转码中间态、文档编辑器的自动保存快照
- 优势明显：1GB 视频写入内存峰值可压到几十 MB；支持
await fileHandle.createWritable()持续追加；崩溃后已写入部分不丢失 - 注意点：不能直接按字段查内容，需自己解析文件；暂不支持跨域共享；Chrome ≥ 86 / Edge ≥ 87 / Safari 尚未支持（截至 2026 年 10 月）
混合使用更常见：用 IndexedDB 管元数据，OPFS 存原始文件
真实项目里很少二选一。典型做法是把“什么文件、谁创建、时间戳、状态、缩略图 URL”存在 IndexedDB，而把视频本体、工程文件、导出包放在 OPFS 目录下。
- 好处：查询快（查 DB）、加载稳（读文件）、扩展性强（新增文件类型只需改路径逻辑）
- 示例：录屏工具保存一条记录：
{id: 'rec_abc', path: '/videos/rec_abc.mp4', duration: 128, status: 'ready'}→ 存 DB；/videos/rec_abc.mp4文件 → 存 OPFS - 衔接方式：OPFS 返回的
FileSystemFileHandle可序列化为字符串存进 IndexedDB，后续用self.getDirectoryHandle().getFileHandle(path)拿回
还要考虑构建与兼容成本
IndexedDB 是 Web 标准，零依赖、全兼容（IE 除外），调试靠 DevTools Application 面板即可；OPFS 需要处理降级（比如 fallback 到 IndexedDB 存 Blob）、权限检测、以及 Web Worker 中调用同步句柄的额外封装。
- 团队熟悉度高、MVP 要快、目标浏览器含 Safari → IndexedDB 更稳妥
- 产品强依赖大文件稳定性、已有 WebWorker 架构、主力用户用 Chrome/Edge → OPFS 投入产出比高
- RxDB 或 PGlite 等方案已接入时，切换存储常只改一行配置（如
storage: getRxStorageIndexedDB()→storage: getRxStorageOPFS()），迁移成本被大幅压缩
