500MB大文件临时存储方案选型：Cache Storage与IndexedDB的速度及安全性对比

嘿，针对你提到的500MB文件上传中途可能跳转登录、回来要续传的场景，我来帮你拆解Cache Storage和IndexedDB的优劣势，尤其是速度和安全性方面的对比：

一、速度表现：Cache Storage更适配大二进制文件 #

咱们先聊最影响续传体验的速度——毕竟500MB的大文件，读写快慢直接决定了用户回来后能不能快速恢复上传：

• Cache Storage：它从设计之初就是为高效处理二进制资源（比如网页图片、JS文件）而生，对Blob类型的文件天生友好。存500MB文件时，不管是整存还是分片存储，几乎没有序列化/反序列化的额外开销，底层直接操作二进制流，读写延迟极低。尤其是上传分片时，每传完一块就存到Cache里，回来续传时读取分片的速度非常快，完全能跟上上传节奏。
• IndexedDB：虽然也能存Blob，但它的核心定位是结构化数据存储。存大二进制文件时，需要把Blob序列化后存入，读取时再反序列化，这会额外消耗CPU和时间，500MB的文件这个损耗会特别明显。而且IndexedDB的事务机制虽然严谨，但对于大文件的分块读写来说，事务的开销会进一步拖慢速度，续传时的分片读取效率远不如Cache Storage。

二、安全性与生命周期：各有侧重 #

两者都严格遵循浏览器同源策略，只有同域名的脚本才能访问，基础安全门槛是一致的，但在存储生命周期和操作风险上有区别：

• Cache Storage：
  • 它被浏览器归类为“缓存数据”，而非持久化存储。如果浏览器磁盘空间不足，可能会优先清理Cache里的内容——不过对于你这种短期临时存储（用户登录回来的时间一般不会太长），这个风险其实很低。
  • API设计非常简洁，操作逻辑简单，比如用cache.put()存分片、cache.match()读分片，几乎不会出现事务锁死、数据冲突的问题，误操作导致数据丢失的概率也更小。
• IndexedDB：
  • 支持申请持久化存储（通过navigator.storage.persist()），一旦获得用户授权，浏览器不会轻易清理数据，稳定性更强。但这个授权流程可能会打断用户的上传操作，影响体验。
  • 事务机制更严谨，适合复杂的数据操作，但对于临时存储大文件的场景来说，反而容易因为事务超时、锁冲突导致数据写入失败，增加了操作风险。另外，如果忘记主动删除临时数据，这些文件会一直留在用户本地，可能占用磁盘空间。

三、针对你的场景的选型建议 #

如果你最在意续传的流畅度和操作简单性，优先选Cache Storage——它的读写速度快，API简单，完全能支撑500MB文件的分片临时存储，只要用户在短时间内完成登录返回，浏览器不会随便清理缓存。

如果你的用户经常出现长时间中断上传的情况，或者特别担心缓存被清理导致续传失败，那可以考虑IndexedDB，但要提前告知用户需要授权持久化存储，避免体验落差。

另外你提到的FileSystemAccess API，确实目前浏览器支持度有限，暂时不适合作为通用方案。

备注：内容来源于stack exchange，提问作者Shairil Kansal