Service Worker 似乎会在某个时候自动停止。此行为无意中关闭了在激活时建立的 WebSocket 连接。
何时以及为何停止？如何以编程方式禁用此意外操作以保持 Service Worker 继续运行？
【问题讨论】：
您看到的是预期的行为，而且不太可能改变。
Service Worker 的寿命故意很短。他们为响应特定事件而“出生”（install、activate、message、fetch、push 等），执行任务，然后不久之后“死亡”。生命周期通常足够长，以至于在工人死亡之前可能会处理多个事件（即install 后面可能跟着activate 后面跟着fetch），但它最终会死亡。这就是为什么不要依赖脚本中的任何全局状态以及在服务工作者启动时通过 IndexedDB 或缓存存储 API 引导所需的任何状态信息非常重要的原因。
Service Worker 是在您访问特定网页时安装的有效后台进程。如果允许这些后台进程无限期运行，则会增加对设备/计算机的电池和性能产生负面影响的风险。为了降低这种风险，您的浏览器只会在它知道有必要时运行这些进程，即响应事件。
WebSockets 的一个用例是让您的客户端监听来自服务器的一些数据。对于该用例，使用WebSockets 的服务工作者友好替代方案是使用Push Messaging API 并让您的服务工作者响应push 事件。请注意，在当前的 Chrome 实现中，您必须在处理 push 事件时显示用户可见的通知。目前不支持“静默”push 用例。
如果您不使用来自服务器的数据，而是使用WebSockets 作为将数据从客户端发送到服务器的一种方式，那么不幸的是，没有很好的服务工作者友好的方式来做到这一点。在未来的某个时候，可能有一种方法可以注册您的服务工作者，以便通过基于周期性/时间的事件唤醒您，此时您可以使用fetch() 将数据发送到服务器，但目前不支持在任何浏览器中。
P.S.：Chrome（通常）在您打开 DevTools 界面时不会杀死服务工作者，但这只是为了简化调试，而不是您应该依赖于真实应用程序的行为。
【讨论】：
[destroy][keep alive][ ] 不要再问”会让我开心
理论
Jeff's answer explains 理论部分 - 为什么和如何，详细。
它还包含许多关于您可能不想追求这一点的好处。
但是，在我的情况下，缺点是不存在的，因为我的应用程序将在桌面计算机上运行，而这些计算机仅用于运行我的应用程序。但是即使浏览器窗口被最小化，我也需要保持 SW 活着。因此，如果您正在开发将在各种设备上运行的 Web 应用程序，那么对于上述答案中讨论的事情，保持 SW 活动可能不是一个好主意。
话虽如此，让我们转向实际的实际答案。
我的“实用”解决方案
应该有很多方法可以让 SW 保持活力，因为 SW 在响应许多不同的事件后会保持活力。就我而言，我将一个虚拟文件放到服务器上，将其缓存在 SW 中，并定期从 document 请求该文件。
因此步骤是；
ping.txt
示例
// in index.html
setInterval(function(){
fetch('/ping.txt')
}, 20000)
请求不会真正到达服务器，因为它会被缓存在 SW 上。尽管如此，这将使 SW 保持活动状态，因为它会响应 fetch 甚至是由请求引起的。
PS：我发现 20 秒是保持 SW 活跃的一个很好的时间间隔，但它可能会改变你，你应该尝试看看。
【讨论】：