很多人，包括我自己，初看Service Worker多一个Cache Storage的时候，就感觉跟HTTP长缓存没什么区别。

例如大家讲的最多的Service Worker能让网页离线使用，但熟悉HTTP缓存的朋友，会发现，把整站所有资源设置为长缓存（不带校验），也可以实现离线使用。

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

带着这个疑问，我翻阅了一些大神博客

JakeArchibald的《》

李熠的《》

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

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标签。

7、前置处理。

例如校验html/JS是否被运营商劫持？js文件到了UI进程执行后，就无法删除恶意代码，而在SW中，我们可以当作文本一样，轻松解决。当然，在HTTPS环境下出现劫持的概率是极低的。