问题描述
我有一个Web应用程序，当前正在使用AppCache进行离线存储。我正在尝试将此应用转换为使用Service Workers。我使用this source作为Service Worker的基础，除了Service Worker是使用PHP构建的，以便动态生成要缓存的文件数组。 / p>
问题在于，用户点击的第一页是登录页面，在此阶段，我们对该用户一无所知，因此我们不知道要缓存哪些资源。我用两个清单来AppCache解决了这个问题。 Login页面的一个清单，所有其他页面使用的第二个清单。当我转换为Service Workers时，我想到了遵循相同的模式。有两个Service Workers-一个用于“登录”页面，另一个用于所有其他页面。
应用程序文件夹结构如下：
-共享 -页数 - 登录 -第1页 - 第2页 -第3页
登录页面和各个页面都使用Shared文件夹中的代码，因此Service Workers的范围都必须是应用程序的根。问题就在这里。现在，我发现我只能在具有根作用域的域上注册一个Service Worker。我可以在Service Worker范围的Login页面上注册第二个/Pages/Login，但是这样将无法访问共享资源。如果我在登录页面和其他页面上都使用相同的Service Worker，则注册会在登录页面上发生，并且生成的URL列表不完整，因为它仅包含登录使用的资源。
我很想知道是否有人处理过此问题，并可能提出解决该问题的可能方向。
解决方法
服务工作者可以访问其[centos@hp-gpu-node2 ~]$ sudo docker exec -t -i 415bc97a940 stat -c %a /var/lib/kube-proxy/config.conf
777
[centos@hp-gpu-node2 ~]$
之外的URL资源（即响应fetch事件）。这包括“较高”级别的URL（例如您的scope目录）或完全不同来源的URL（例如CDN）。
/Shared限制确定给定的服务工作者是否可以控制位于给定URL的网页。服务人员只能控制URL以scope为前缀的网页。
因此，您可以创建多个服务工作者，并使用与不同URL前缀匹配的scope来注册每个服务工作者，并且每个服务工作者都可以响应共享资源URL的scope事件。
https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#scope_and_control
中有更多信息