别再使用IndexedDB，大文件读写就用OPFS
内容提要
OPFS（源私有文件系统）是Web本地存储方案，比IndexedDB更简单高效，适合缓存大文件如中文字体。通过案例展示首次请求后本地持久化，实现秒开。OPFS无需弹窗，受浏览器配额管理，兼容Chrome 86+，而File System Access API需用户交互且仅Chrome支持。建议大文件存储优先用OPFS。
延伸解读
OPFS与IndexedDB的取舍
文章指出，对于大文件的本地持久化存储，OPFS在性能和代码简洁性上优于IndexedDB。IndexedDB适合存储结构化数据或需要索引查询的场景，而OPFS更适合大二进制文件（如字体、音视频）的缓存。开发者应根据数据类型和查询需求选择合适的存储方案，避免盲目使用IndexedDB。
OPFS与File System Access API的差异
OPFS是File System API的核心，所有现代浏览器均支持，无需用户交互即可在后台读写，但文件位于浏览器沙盒中，用户不可见。File System Access API则需用户主动选择文件，仅Chrome支持，且权限会失效。OPFS适合Web应用内部缓存，而FSA适合需要用户管理本地文件的场景。
中文字体本地缓存的实践意义
完整中文字体文件约3-6MB，通过OPFS首次加载后本地持久化，后续访问可实现秒开，无需网络请求。这改变了以往需动态生成字体的做法，使得全局引入中文字体成为可能。但需注意，OPFS受浏览器配额限制，且清除站点数据会删除缓存，开发者需权衡存储空间与用户体验。
Q&A
OPFS是什么？它和IndexedDB相比有什么优势？
OPFS（源私有文件系统）是浏览器提供的一种文件系统，通过navigator.storage.getDirectory()访问。相比IndexedDB，OPFS读写大文件更简单高效，代码简洁，性能更好，适合缓存大文件如中文字体。
如何使用OPFS缓存中文字体并实现秒开？
首次加载时，通过fetch获取字体文件，用root.getFileHandle创建文件句柄，再通过createWritable()将响应流写入OPFS。之后每次加载，直接从OPFS读取字体文件，注册为FontFace，实现秒开。
OPFS和File System Access API有什么区别？
OPFS是浏览器内部沙盒文件系统，无需用户交互即可访问，受浏览器配额管理，兼容Chrome 86+等现代浏览器。File System Access API需要用户主动选择文件，仅Chrome支持，直接读写用户磁盘文件。
OPFS的浏览器兼容性如何？
OPFS支持Chrome 86+，以及Safari和Firefox等现代浏览器（具体版本未提及，但文章称所有现代浏览器支持）。
OPFS适合存储哪些类型的数据？
OPFS适合存储大二进制文件，如字体、音视频片段、本地草稿文件，以及需要字节级随机读写或追加写入的场景。
OPFS的存储容量和持久性如何？
OPFS受浏览器origin总配额限制，通常为几十到几百MB，持久存储，清除站点数据时删除。
为什么说大文件存储优先用OPFS而不是IndexedDB？
因为OPFS性能更高，代码更简单，且支持流式写入，避免大文件整体驻留内存。IndexedDB语法复杂，大Blob存取有内存开销。除非需要存储结构化数据或兼容老旧设备，否则OPFS是更好的选择。
