OPFS 重构了 Web 应用处理数据的方式，提供原生级文件系统语义和流式吞吐能力，支撑视频编辑、离线 IDE 等专业场景；其核心是从“键值对”跃迁至“文件流”，支持随机读写、边写边存、Worker 同步访问及原子文件操作。
OPFS 不是简单地“把文件存得更大”，而是重构了 Web 应用处理数据的方式——它让浏览器拥有了接近原生应用的文件系统语义和吞吐能力，从而支撑起视频编辑、离线 IDE、本地化 AI 模型加载等过去只能依赖桌面端的场景。
OPFS 的核心突破：从“键值对”到“文件流”
传统 Web 存储（如 localStorage、IndexedDB）本质是结构化键值存储，操作单位是“条目”，读写需序列化/反序列化，无法直接寻址二进制块。而 OPFS 提供真正的目录树、文件句柄、流式读写接口（createWritable()、createSyncAccessHandle()），支持：
- 按字节偏移随机读写大文件（例如跳转到视频第 120 秒解码帧）
- 边下载边写入（streaming write），避免内存爆满
- 在 Worker 中用同步句柄实现零拷贝内存映射（如 wasm 模块直接读取 OPFS 文件）
- 原子性追加、截断、重命名等文件系统级操作
对比 IndexedDB：不是更快，而是“可做”的事变了
IndexedDB 虽支持事务和索引，但面对 GB 级图像缓存或 WASM 模块资源包时，性能瓶颈明显：
- 写入 500MB 文件需先转为 Blob 再存入 object store，触发多次 GC 和内存复制
- 读取某一段需加载整个 Blob，再切片，无法真正流式处理
- 没有路径概念，难以组织项目工程结构（如
/project/layers/layer_3.png）
OPFS 则天然支持分层路径管理与局部 I/O，Photopea、Excalidraw 等工具正是借此实现“关闭再开，图层毫秒恢复”。
与 Cache API 的分工：资源缓存 ≠ 用户数据存储
Cache API 专为 HTTP 响应设计，适合静态资源预加载（HTML/CSS/JS），但它：
- 不暴露文件系统路径，无法由 JS 自主创建或修改内容
- 生命周期受 Service Worker 控制，可能被浏览器自动清理
- 不能存储用户生成内容（如用户上传的原始 RAW 照片）
OPFS 是用户数据的“私有工作区”，持久、可控、可编程——它不参与网络请求流程，而是作为应用的数据底盘存在。
新图景的关键特征：隔离、流式、协同演进
OPFS 正在推动三个底层变化：
- Origin 隔离即安全边界：无需用户授权即可使用，规避权限疲劳；同一站点跨 Tab 共享，天然适配多窗口协作场景
- 流式能力催生新架构：wa-sqlite 可将 SQLite 的 VFS 直接挂载到 OPFS，使 Web 应用拥有“嵌入式数据库 + 文件系统”双栈能力
-
与 Storage Buckets 协同演进：未来可通过
navigator.storageBuckets对 OPFS 数据按用途分桶（如user-docs桶设为永驻，temp-cache桶设为可回收），实现精细化生命周期治理
这不是对旧方案的替代，而是补全了 Web 平台缺失的“高性能文件层”，让网页真正具备承载专业生产力工具的底层能力。
