很多人，包括我自己，初看Service Worker多一个Cache Storage的时候，就感觉跟HTTP长缓存没什么区别。
例如大家讲的最多的Service Worker能让网页离线使用，但熟悉HTTP缓存的朋友，会发现，把整站所有资源设置为长缓存（不带校验），也可以实现离线使用。

那么，Service Worker在缓存方面和HTTP缓存比较，有什么好处呢？

带着这个疑问，我翻阅了一些大神博客
JakeArchibald的《Caching best practices & max-age gotchas》
李熠的《设计一个无懈可击的浏览器缓存方案：关于思路，细节，ServiceWorker，以及HTTP/2》

根据实际项目经验，总结出以下。

Service worker除了针对PWA（推送和消息）以外，对普通web来说，在缓存方面，能比http缓存带来一些额外的好处。
可以理解为，SW就是浏览器把缓存管理开放一层接口给开发者。

1、改写默认行为。

 例如，浏览器默认在刷新时，会对所有资源都重新发起请求，即使缓存还是有效期内，而使用了SW，就可以改写这个行为，直接返回缓存。

2、缓存和更新并存。

 要让网页离线使用，就需要整站使用长缓存，包括HTML。而HTML使用了长缓存，就无法及时更新（浏览器没有开放接口直接删除某个html缓存）。而使用SW就可以，每次先使用缓存部分，然后再发起SW js的请求，这个请求我们可以实施变更，修改HTML版本，重新缓存一份。那么用户下次打开就可以看到新版本了。

3、无侵入式。

 无侵入式版本控制。最优的版本控制，一般是HTML中记录所有js css的文件名（HASH），然后按需发起请求。每个资源都长缓存。而这个过程，就需要改变了项目结构，至少多一个js或者一段js控制版本号，发起请求时还需要url中注入冬天的文件名。使用了SW，就可以把这部分非业务逻辑整合到sw js中。
 无侵入式请求统计。例如缓存比例统计、图片404统计。

4、额外缓存。

 HTTP缓存空间有限，容易被冲掉。虽然部分浏览器实现SW的存储也有淘汰机制，但多一层缓存，命中的概率就要更高了。

5、离线处理。

 当监测到离线，而且又没有缓存某个图片时，可以做特殊处理，返回离线的提示。又或者做一个纯前端的404/断网页面。例如Chrome的小恐龙页面。

6、预加载资源。

这个类似prefetch标签。

版权声明：本文为kenkofox原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/kenkofox/p/8732428.html