构建PWA时存储含数据列表的API响应：sw-toolbox缓存VS IndexedDB离线存储？

这个问题问得很实在，在PWA开发里处理带数据列表的API响应缓存，真不是选A就不能选B的事儿，得看你的业务场景来。咱先把sw-toolbox和IndexedDB的核心差异捋明白，再给你落地的建议：

先搞懂俩方案的优劣势 #

• sw-toolbox（推荐升级到Workbox）：这是在HTTP缓存层面干活的，缓存的是整个API响应的原始数据（比如JSON字符串）。
  • 优点：拦截请求快，代码实现简单，适合那种静态、不常变、对实时性要求不高的列表，比如网站的分类导航、帮助中心的FAQ列表。
  • 缺点：缓存容量有限（浏览器HTTP缓存一般也就几十MB顶破天），没法精细操作数据（比如只更新列表里某一条），缓存策略是针对整个请求的，灵活度不高。
• IndexedDB：这是客户端的结构化数据库，能把API返回的JSON转成对象存起来，还支持复杂查询、增删改单条数据。
  • 优点：容量大（几百MB甚至几GB，看浏览器），适合动态、需要频繁更新、要精细操作的列表，比如用户的订单、收藏夹、待办事项。
  • 缺点：操作相对繁琐，得自己写DB的增删改查逻辑，而且没法直接拦截网络请求返回数据，得在代码里手动判断离线状态，从DB取数返回。

最优实践：分场景搭配使用 #

场景1：静态/半静态列表 #

用sw-toolbox/Workbox的Network First + 缓存兜底策略就行。在线时先拉最新数据更新缓存，离线时直接用缓存的响应。代码示例大概是这样：

// sw-toolbox示例
toolbox.get('/api/static-categories', toolbox.networkFirst({
  cache: {
    name: 'static-category-cache',
    maxEntries: 15 // 限制缓存条目数
  }
}));

这种场景下不需要折腾数据库，HTTP缓存足够用，开发成本低。

场景2：用户相关的动态列表 #

这种就得IndexedDB存数据，搭配Service Worker拦截请求。在线时请求API，拿到数据后同步更新IndexedDB；离线时Service Worker拦截页面的API请求，从IndexedDB里读取结构化数据返回给页面。
比如用户离线时新增了一条待办，能先存在DB里，等恢复网络后再同步到服务器，体验会好很多。这里推荐用封装好的库（比如Dexie.js、localForage）来简化IndexedDB的操作，少写重复代码。

场景3：兼顾性能和灵活性的列表（比如商品列表） #

可以搞双缓存策略：用sw-toolbox缓存整个API响应做快速兜底（保证离线时页面能快速加载），同时把数据存入IndexedDB做精细操作（比如用户离线时筛选商品）。在线时优先用网络获取最新数据，同时更新缓存和DB；离线时先返回缓存的响应让页面快速渲染，后台再从DB读取更完整的结构化数据补充到页面里。

额外提醒 #

• 如果你还在维护sw-toolbox的代码，建议尽快升级到Workbox——它是sw-toolbox的官方升级版，API更友好，支持更多缓存策略，还能自动生成Service Worker，省不少事儿。
• 不管用哪种方案，一定要处理缓存更新的问题：比如给缓存加版本号，或者用ETag、Last-Modified头验证数据是否过期，别让用户一直看到旧数据。

内容的提问来源于stack exchange，提问作者Amit Singh