前言
相信各位前端同学对浏览器端存储API完全不会陌生，像 cookie、localStorage、sessionStorage、IndexedDB 等都已非常熟悉。然而，对于源专用文件系统 （Origin Private File System，简称 OPFS），大概有 90% 的前端工程师并不了解，甚至从未听说过。
在说明 OPFS 之前，先考虑一个问题：
在 Web 端，如果我们需要存储一个文件，你会如何处理？
如果文件不大，或许可以考虑使用 localStorage 或 sessionStorage，但是这些存储方式的大小受到浏览器的限制，当文件较大时，就不太合适了。
这时候，可以考虑使用 IndexedDB，但是在存储文件方面，OPFS 是一个更好的选择。
OPFS优点
| 存储方式 | 存储空间大小 | 存储时效性 |
|---|---|---|
| Cookie | 每个 Cookie 大约 4KB ，总数约 300-400 | 可设置到期时间，或随浏览器会话结束而删除 |
| LocalStorage | 每个域名通常 5-10MB | 持久存储，除非手动清除，否则数据一直存在 |
| SessionStorage | 每个域名通常 5-10MB | 会话级别，浏览器标签页或窗口关闭时数据删除 |
| IndexedDB | 通常 数百MB 到 几GB | 持久存储，除非手动清除，否则数据一直存在 |
| OPFS | 数GB 到 几十GB，由设备磁盘空间决定 | 持久存储，除非手动清除或用户明确授权清理数据 |
大文件存储能力
OPFS 的设计初衷就是为了支持大文件的存储和管理 。与其他存储方式相比，它可以轻松处理几十 MB 甚至 GB 级别的文件，这在传统的 LocalStorage 和 IndexedDB 中是非常困难的。
而且它允许开发者以块（chunk）形式读写文件，而无需一次性加载整个文件到内存中。这对于处理音视频、图像等大文件尤其有用。
持久性与持久存储
OPFS 能够持久存储数据，确保文件不会轻易丢失。意味着文件系统内的数据不会在浏览器关闭后自动清除，而是长期存储。
用户可以明确控制数据的生命周期，这使得 OPFS 在需要长期保存数据的应用场景（例如离线应用、PWA 应用）中具有明显的优势。
性能优化
OPFS 直接对文件进行操作 ，不需要像 IndexedDB 那样先将文件转成二进制对象（如 Blob）进行存储再读取。因此，在处理文件的读写性能上，OPFS 更加高效。
它支持流式处理，这意味着开发者可以逐块处理文件数据，而不是一次性读取或写入所有数据。这样可以显著降低内存使用，并提升大文件操作的性能。
OPFS 不止可以在主线程中使用，还可以在Web Worker中使用，在Web Worker使用不会阻塞主线程，并且在Web Worker中OPFS可以使用同步语法。
文件系统 API
OPFS 提供了类 Unix 文件系统的 API ，使得开发者可以使用类似 mkdir、open、close、read、write 这样的低级别文件操作，更符合操作文件的习惯，使得开发者可以更灵活地管理文件系统中的目录和文件，而不是像其他存储方式那样只能存储键值对。
因为是类似于文件的操作方式，所以OPFS 可以随机访问文件中的任意部分文件，而不需要像 IndexedDB 那样从头开始读取整个对象，更加高效、便捷
相关生态
浏览器插件
OPFS是页面所属源私有的、对用户不可见的，正常情况用户是无法看到存储的文件，所以需要对应的浏览器插件OPFS Explorer，查看存储的内容
opfs-tools
opfs-tools (opens new window)基于 OPFS 封装提供简洁的 API，让你能优雅高效地操作文件，总结有以下特性：
- opfs-tools 允许直接读写常见数据类型（文本、二进制、流），无需转换成二进制
- opfs-tools 能直接处理字符串 path，无需循环获取深层级的目录或文件
- opfs-tools 提供便捷的 API 操作 file/dir，如复制、移动、删除
- opfs-tools 自动将读写请求代理到 WebWorker，性能更好
opfs-tools-explorer
opfs-tools-explorer (opens new window)是基于 opfs-tools 项目开发的可视化工具，和上面提到的浏览器插件一样，可以查看到OPFS存储的内容。