我试图了解skipWaiting和clientsClaim之间的区别。据我了解：调用skipWaiting将导致新服务人员跳过等待阶段，并立即变为活动状态。 clientsClaim然后也可以“声明”其他任何打开的标签页。
我从在线文档中收集的信息：
在网上找到的每条信息中，通常总是会同时看到clientsClaim和skipWaiting一起使用。
但是，我最近发现了一个仅使用clientsClaim的服务人员，我很难理解clientsClaim和skipWaiting之间的区别是什么，在什么情况下您使用clientsClaim但不使用{em> skipWaiting？
我对此进行了思考，这可能是我错了，但这是我对此的理解：
调用clientsClaim而不是skipWaiting是多余的吗？考虑：
skipWaiting），新的服务工作者将变为活动状态clientsClaim。应该没有其他页面可以控制，因为我们只是关闭了它们。有人可以帮助我理解吗？
阅读有关skipWaiting的文档
阅读有关clientsClaim的文档
了解杰克·阿奇博尔德（Jake Archibald）的service worker lifecycle，并与this demo一起玩
阅读一堆stackoverflow帖子，离线食谱，不同的博客帖子等。
答案 0 :(得分：2)
self.skipWaiting()完全符合您的描述：
强制等待服务的工作人员成为活动服务
从这个意义上讲，“活动”并不意味着任何当前加载的客户端现在正在与该服务通信。相反，它意味着该服务现在是新客户端请求时要使用的服务。
这是Clients.claim()出现的位置：
最初注册服务工作者时，页面只有在下一次加载时才会使用它。
在不调用claim的情况下，任何现有客户端仍将继续与较旧的服务程序进行通信，直到整个页面加载完毕。
在大多数情况下，结合使用skipWaiting和Clients.claim是有意义的，但并非总是如此。如果由于服务工作者不向后兼容而给用户带来糟糕的体验，则不应调用Clients.claim。取而代之的是，下一次刷新或加载客户端时，它现在将具有新的服务工作程序，而无需担心更改会大打折扣。
答案 1 :(得分：0)
要理解的一个重要概念是，要使服务工作者在页面上开始操作，它必须是页面的 controller 。 （实际上您可以在Navigator.serviceWorker.controller中看到此属性。）要成为控制器，必须先激活服务工作者，但仅此一项是不够的。如果页面也已通过服务人员请求，则只能对其进行控制。
通常是这种情况，尤其是在您仅更新服务工作者时。另一方面，如果您是第一次在页面上注册服务工作者，那么将安装并激活该服务工作者，但由于未通过服务请求该页面，因此该服务工作者不会成为该页面的控制器。工人。
您可以通过在激活处理程序中的某处调用Clients.claim()来解决此问题。这只是意味着您无需刷新页面即可看到服务工作者的效果。
有人怀疑这实际上有多有用。规范的作者之一杰克·阿奇博尔德（Jake Archibald）对此this说：
我看到包括client.claim（）在内的很多人都是样板，但我自己很少这样做。仅在第一次加载时才真正重要，并且由于逐步增强，页面通常在没有服务人员的情况下也能愉快地工作。
关于其与其他选项卡一起使用，仅当服务工作人员未请求这些选项卡时，它才会再次生效。可能出现这样的情况：用户在不同的选项卡中打开了同一页面，并且长时间打开了这些选项卡，在此期间开发人员介绍了服务工作者。如果用户刷新一个选项卡，但不刷新另一个选项卡，则一个选项卡将具有服务工作程序，而另一个则不会。但是这种情况似乎并不常见。
安装后，如果没有其他服务工作人员正在控制范围内的页面，则会激活服务工作人员。换句话说，如果为旧服务工作者正在控制的页面打开任意数量的选项卡，则新服务工作者将不会激活。因此，您可以通过关闭所有打开的选项卡来激活新的服务工作者。此后，旧的服务程序正在控制零页，因此新的服务程序可以处于活动状态。
如果您不想等待老服务人员被杀死，可以致电skipWaiting()。通常，这是在install事件处理程序中完成的。即使旧的服务人员正在控制页面，它还是会被杀死，这可以激活新的服务人员。