PWA仅读数据场景下 用缓存JSON替代indexedDB有何局限？

首先明确：如果你当前的本地数据量小、只需要全量读取、数据丢失后可以方便地从服务端重新拉取，你现在用的Cache缓存JSON+fetch读取的方案完全可用，不存在必须换成IndexedDB的硬性要求。但这个方案确实存在几个设计层面的固有局限，也是行业内普遍推荐IndexedDB作为本地结构化存储方案的核心原因：

• 存储留存优先级更低
  Cache API从设计之初就是服务于Service Worker的网络资源缓存场景，不属于站点持久化存储的核心范畴。当用户设备存储空间不足时，浏览器会优先清理Cache内的资源，整个清理过程不会给页面发送任何通知，你下次调用fetch读取缓存时会直接命中失败，只能重新走网络请求拉取数据。相比之下，IndexedDB属于站点持久化存储的一部分，存储配额更高，触发自动清理的阈值更严格，数据留存的可靠性远高于Cache。
• 大数据量下的性能差距明显
  存在Cache里的JSON本质是一整个文本文件，每次读取都要把完整文件拉取到内存，全量反序列化成JS对象后才能使用——哪怕你实际只需要用到其中1%的字段，也要承担整个文件的解析开销。当JSON体积超过10MB之后，这个解析过程很容易卡住主线程，造成页面交互卡顿。而IndexedDB是结构化的事务数据库，支持字段索引、条件查询，可以只拉取你需要的部分数据，不需要全量加载解析，数据量越大性能优势越明显。
• 存储容量上限更低
  不同浏览器对Cache的单域名配额限制普遍更严格，多数移动端浏览器给Cache分配的空间仅占域名总存储配额的10%~20%，而IndexedDB通常可以使用设备剩余可用存储空间的50%以上。如果后续你的本地数据规模增长到几十MB级别，Cache很容易触发配额写入错误，IndexedDB的容量冗余度要高很多。
• 没有事务保障，数据一致性差
  Cache的操作粒度是整个HTTP响应对象，不支持局部修改——哪怕你只需要更新JSON里的一个字段，也要把整个JSON重新序列化后全量覆盖写入。虽然你当前没有写入需求，但如果后续需要新增增量更新、多标签页同时操作本地数据的能力，Cache没有事务机制，很容易出现写入覆盖、文件损坏的脏数据问题。而IndexedDB原生支持事务机制，能保证操作的原子性，不会出现半写入的损坏数据。
• 兼容性边界更模糊
  部分浏览器的无痕模式、站点权限被收回的场景下，会直接禁用Cache的持久化能力，页面关闭后缓存内容就会被清空。而IndexedDB的存储规则在各浏览器里的实现更统一，哪怕是无痕模式下也能保证当前会话内的存储可用，行为预期更稳定。

如果你的使用场景满足以下所有条件，继续用Cache存JSON的方案完全没有问题：

• 本地JSON数据体积在10MB以内
• 每次读取都需要用到全量数据，不需要按需查询部分条目
• 缓存数据丢失不会影响核心功能，随时可以从服务端重新拉取完整数据
• 长期没有本地写入、增量更新数据的需求

内容的提问来源于stack exchange，提问作者Carlos Toscano-Ochoa