浏览器端大文件存储指南

1. 前言：常见误区与真实痛点

在浏览器端处理大文件（尤其是视频录制、编辑、转码等场景）时，很多开发者会踩到一个非常典型的“前端直觉坑”：

直觉选择：localStorage 太小、sessionStorage 不持久、cookie 不可能，最后选择用 IndexedDB 存 Blob。
实际问题（长视频场景下暴露明显）：
- 内存占用持续升高（尤其是 Blob 反复读写时）。
- 写入/读取性能不稳定，不同浏览器差异大。
- 浏览器崩溃后，录制中的中间数据难以恢复。
- 导出/转码时需要把整段视频重新加载到内存，速度慢、易卡顿甚至崩溃。

核心原因是：IndexedDB 更适合存储“结构化数据”，而非“文件系统式”的持续读写工作流。它不是为大文件流式处理设计的。

推荐方案是切换到 OPFS（Origin Private File System）。
OPFS 更接近真实的文件系统，特别适合“大文件 + 高性能 + 高稳定性”的场景。

存储方式	存储原理	主要使用内存的时机	主要使用磁盘的时机	容量限制	适合大文件？
localStorage	key-value 字符串存储（底层 SQLite 等）	读取/写入时加载到 JS 内存（必须字符串化）	数据持久化在磁盘	~5-10MB	不适合
sessionStorage	与 localStorage 类似	几乎全程在内存中	基本不持久化	~5MB	不适合
Cookie	小段文本（持久/会话）	session cookie 在内存	持久 cookie 存磁盘	~4KB/个	完全不适合
IndexedDB	异步 NoSQL 对象数据库，支持 Blob	创建 Blob、`put/get` 时（复制、缓冲、反序列化），反复读写易产生峰值	数据最终落盘（大 Blob 可能单独存文件）	较大（共享 origin 配额）	中等适合（短视频可，长视频有坑）
OPFS	真正的文件系统 API，支持目录与文件	显著降低（支持流式、chunk 写入，无需整段 Blob 常驻内存）	持续落盘，支持边录边写	较大（共享 origin 配额）	强烈推荐

关键结论：

更像“文件系统”而非“数据存储”：支持按 chunk 持续写入，适合录制过程中边产生边落盘。
内存压力大幅降低：无需将整段视频长期以 Blob 形式驻留内存。
崩溃恢复能力强：即使浏览器意外退出，已写入的文件部分仍有较大机会保留。
导出/转码更高效：可直接从文件系统读取，支持流式处理，内存和 CPU 占用更低。
Worker 支持：可在 Dedicated Web Worker 中使用同步文件 API（createSyncAccessHandle），不阻塞主线程，适合视频处理、转码等重 I/O 操作。

推荐链路（以录屏工具为例）：

适用场景：

没有固定大小：与 IndexedDB、Cache Storage 等共享 origin 存储配额，实际可用空间取决于设备剩余磁盘空间，通常从几百 MB 到数十 GB 不等。
各大浏览器大致规则（2026 年）：
- Chrome / Edge：origin 约可使用磁盘容量的 60%。
- Firefox：持久化后可达磁盘 50%（有上限）。
- Safari：通常较高，基于可用空间动态分配。
如何管理与控制（无法直接设置硬限制，但可有效优化）：
- 查询空间：navigator.storage.estimate()（可查看总配额、已用空间、OPFS 具体占用）。
- 请求持久化存储：navigator.storage.persist()（推荐在首次录制前调用，防止浏览器自动清理中间文件）。
- 处理配额超限：捕获 QuotaExceededError，提前提示用户或分段处理。

实用建议：长视频录制工具应在应用启动或录制开始前，主动检查空间并申请持久化。

最推荐方式：安装 OPFS Explorer Chrome 扩展。
- 在 Chrome Web Store 搜索 “OPFS Explorer” 并安装。
- 打开 DevTools，出现 “OPFS Explorer” 面板后，可浏览文件树、查看文件大小、下载或删除文件。
备选方式（无需扩展）：
- 在 Console 中运行递归遍历代码，打印所有文件和目录。
- 使用 navigator.storage.estimate() 查看整体占用情况。
- 在 Application -> Storage 面板查看整个 origin 的存储概览，并一键清空站点数据（用于测试）。

注意：必须在安全上下文（HTTPS 或 localhost）下才能访问 OPFS。