Service Worker和Shared Worker有什么区别？
什么时候应该使用Service Worker而不是Shared Worker，反之亦然？
服务工作者具有超出共享工作者可用功能的其他功能，并且一旦注册，它们将在给定网页的生命周期之外持续存在。
服务工作者可以响应message事件，例如共享工作者，但他们也可以访问其他事件。处理fetch事件允许服务工作者拦截任何网络流量（源自受控页面）并采取特定操作，包括提供来自Request / Response缓存的响应。还有plans向服务工作者公开push事件，允许网络应用程序在“背景”中接收推送消息。
另一个主要区别与持久性有关。一旦服务工作者注册了特定的来源和范围，它就会无限期地保持注册状态。 （如果底层脚本发生更改，服务工作者将自动更新，并且可以手动或以编程方式删除，但这是例外。）因为服务工作者是持久的，并且具有独立于Web浏览器中活动页面的生命它打开了诸如使用它们为上述推送消息传递提供动力的大门 - 只要浏览器正在运行，服务工作者就可以“醒来”并处理push事件，无论哪个页面处于活动状态。未来的Web平台功能也可能会利用这种持久性。
还有其他技术差异，但从更高层次的角度来看，这些是突出的。
SharedWorker上下文是一个有状态会话，旨在通过异步消息传递（客户端/服务器范例）将网页复用到单个应用程序中。它的生命周期是基于域的，而不是像DedicatedWorker（双层范例）这样的单页面。
ServiceWorker上下文设计为无状态。它实际上根本不是持久会话 - 它是控制反转（IoC）或基于事件的持久性服务范例。它提供活动，而不是会议。
一个目的是为数据库和其他持久性服务（即云）的长期运行查询（LRQ）提供并发安全异步事件。正是线程池在其他语言中的作用。
例如，如果您的Web应用程序为各种云服务执行许多并发安全LRQ以填充自身，那么ServiceWorkers就是您想要的。您可以立即执行数十个安全LRQ，而不会阻止用户体验。 SharedWorkers和DedicatedWorkers不能轻易处理许多并发安全LRQ。此外，某些浏览器不支持SharedWorkers。
也许他们应该称之为ServiceWorkers：为了清晰起见，CloudWorkers，但并非所有服务都是云。
希望这个解释可以引导您思考各种工作者类型如何设计为一起工作。每个都有自己的专业化，但共同的目标是减少DOM延迟并改善基于Web的应用程序的用户体验。
扔一些WebSockets用于流媒体和WebGL用于图形，你可以构建一些像multiplayer console games一样的吸烟热门网络应用程序。