浏览器内置了一个文件系统，但 90% 的人还在用 IndexedDB

写过前端的人装了无数 IndexedDB 封装库，每次想追加一段数据都要先设计好 schema 结构，想存个大文件还要折腾 Blob 分片。今天这件事被浏览器内置的 Origin Private File System 从根上翻了——它不是新玩具，而是所有现代浏览器从 2023 年开始就默默支持的私有文件系统，性能比 IndexedDB 高出一截。

OPFS 的入口极简，就是一行 navigator.storage.getDirectory()。拿到根目录句柄后，可以像操作本地文件一样 getFileHandle() 和 getDirectoryHandle()，创建文件、写入内容、读取回来。关键是全程不需要用户授权，不弹任何权限提示——这是浏览器给每个域名单独开辟的私有存储空间，操作系统里的文件管理器根本看不到。

主线程上是异步 API，适合普通读写。如果要追求极致性能，OPFS 在 Web Worker 里暴露了同步句柄 createSyncAccessHandle()，读写都是原地按字节操作，没有 promise 开销，也没有 async/await 的协程切换损耗。这个同步句柄正是 SQLite WASM 能在浏览器里跑起来的底层依赖——SQLite 的事务模型需要能 seek 到任意字节偏移、原地改一小块数据，普通的异步文件 API 根本做不到。

真实数据最能说明问题。用 @componentor/fs 的 benchmark 在 Chromium 上跑，同一个 OPFS 文件系统，VFS 同步模式的读写延迟比纯异步 Worker 模式低 3 到 19 倍；读取操作快 11 倍，写入操作快 3 到 6 倍。micrometre/opfs-sqlite 的实测数据更直观：批量插入每秒 10,000 到 50,000 条记录，带索引的查询在亚毫秒级完成。这不是小众数据——这是所有主流浏览器共享的原生能力。

应用场景很清楚：想用 SQLite 在浏览器端做本地持久化数据库？OPFS 是唯一靠谱的存储后端。想离线缓存大体积音视频剪辑结果？OPFS 的流式写入比 IndexedDB 省心得多。想给 WebAssembly 应用加文件持久化？同步句柄是标配。DevAIToolkit 在 2026 年 6 月的测试里用 OPFS + Pyodide 跑真实数据管道，120,000 行交易记录全表扫描在 M2 MacBook 上 800 毫秒内跑完，整个站点零后端，跑在 Cloudflare Pages 上。Photoshop Web 同样靠 OPFS 管理 PSD 文件的大规模读写。

当然有坑：同步句柄必须在 Web Worker 里用，放主线程会直接报错。OPFS 和 IndexedDB、Cache API 共用同一块存储配额，Chrome 上通常是剩余磁盘空间的 60%，移动端会更紧张，需要主动调用 navigator.storage.persist() 申请持久化权限。数据在浏览器内部是持久的，但如果用户清除了站点数据，文件一样会丢。

判断什么时候该用它：数据天然是文件形态（视频、工程文件、WASM 数据库）→ 用 OPFS；数据是结构化记录、需要索引和事务 → 用 IndexedDB；两者都想要 → OPFS 存文件、IndexedDB 存元数据索引。

下一步：打开 Chrome DevTools → Application → Storage，找到 “Origin Private File System” 一栏，自己跑一个 navigator.storage.getDirectory() 试试。如果你在做本地优先的 Web 应用，这个 API 值得放进技术选型的第一轮讨论里。