重写fetch实现PWA离线缓存的方案可行性及现有工具问询

方案可行性评估 #

重写全局fetch实现无侵入缓存的方案是完全可行的，生产环境也有不少落地案例，但要注意几个核心问题：

• 缓存key需要能唯一标识请求，除了URL之外还要包含请求方法、请求体、请求头等差异化参数，避免POST等非GET请求出现缓存匹配错误
• 要完整兼容原生fetch的所有API特性，包括credentials、signal（取消请求）、异常抛出逻辑等，不要改动原有业务代码的预期行为
• localStorage本身的短板非常明显：同步读写会卡主线程，默认容量只有5~10M，仅适合存少量小体积响应，完全不适合PWA场景下的大量接口缓存需求。

成熟方案推荐 #

你不需要自己从零实现逻辑，目前有两类经过大量生产验证的成熟方案可以直接用：

1. PWA场景首选：Service Worker + Cache API 方案
   这是W3C规范内的PWA离线缓存标准实现，完全不需要修改业务层的fetch调用，在Service Worker线程里就能拦截所有全局请求，容量上限一般是设备磁盘剩余空间的10%，远大于localStorage，而且所有操作都是异步的不会阻塞主线程。
   谷歌官方维护的Workbox是这个方向的首选封装，你要的缓存命中判断、失效策略、网络回退、缓存清理等逻辑都有现成的配置项，只需要几行代码就能完成你预设的所有缓存逻辑，不需要自己重写fetch。
2. 轻量重写fetch方案
   如果你的场景不需要全量PWA能力，只想做轻量的接口缓存，也有现成的fetch封装库，已经处理了参数序列化、缓存冲突、异常降级等边缘场景，直接引入就能用，不需要自己写window.fetch的覆写逻辑。

落地注意事项 #

• 建议给缓存加路由白名单，不要缓存POST提交、带敏感信息、实时性要求极高的接口，避免业务逻辑异常
• 不管用哪种缓存方案，都要配置缓存过期策略、容量上限清理规则，避免旧缓存或者冗余缓存占用过多存储
• 要加异常降级逻辑：缓存读写失败、请求异常时要自动回退到原生请求逻辑，不要因为缓存逻辑影响正常业务运行

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