我正在尝试从AppCache迁移到Service Worker以获得一个大型框架（Construct 2 - 请参阅www.scirra.com）。很容易找到如何使用Service Worker缓存资源列表，然后在fetch事件中使用缓存条目进行响应的示例。但是，我发现AppCache有两个功能，我发现很难与Service Worker一起复制：
这两个都需要识别索引页面（＃2将在请求索引页面的同时检查更新）。然而，我发现自己被引入了看起来不那么优雅的解决方案。请注意，如果请求“foo /”，许多服务器将返回“foo / index.html”，但其他服务器不返回，还有一些服务器使用动态路径，因此我无法列出任何硬编码的主页URL。我必须使用当前页面的URL。
对于＃1，我在“install”事件中跳过了Waiting（），在“激活”中声明了（）客户端，client.matchAll（）迭代每个客户端，然后将client.url添加到缓存中。这看起来有点啰嗦，是不是有办法在“安装”事件中获取主页面URL？
对于＃2，我必须在每个fetch事件中调用clients.matchAll（）并测试当前请求URL是否与任何客户端URL匹配。如果是，它是主页面，我检查更新，否则正常处理。这似乎非常不优雅，因为在页面加载时发生的数百个获取请求中的每一个都必须不断获取所有客户端的列表并匹配其URL。
是否有更好的方法从服务工作者那里获取主页的URL？
答案 0 :(得分：1)
我建议将sw-precache合并到您的构建过程中。它为您生成一个服务工作者脚本，负责预先处理您关注的资源，并在构建期间检测到更改时维护缓存（更新/添加/删除）条目。
sw-precache中的some support用于预先缓存依赖于多个底层模板文件的网址，但您也可以将sw-precache与additional runtime service worker逻辑结合使用。 sw-toolbox是一个很好地补充sw-precache并实现各种运行时缓存选项的库。
即使您没有直接使用sw-precache，也可以从您的代码中获取一些您可以在自己的服务工作者中使用的模式：
Add一个索引文件，如index.html，如果它以/结尾，请求网址。 （在服务工作者中使用Cache Storage API时，将您用作密钥的网址规范化始终是一个好主意。）
依靠service worker lifecycle来触发缓存管理，而不是获取带外＆＃34;清单＆＃34;。当您的浏览器注意到对服务工作者脚本的更改时，它将触发install事件以使您有机会缓存新条目，并发出activate事件以使您有机会进行缓存清理。这意味着每当缓存条目发生更改时，底层服务工作者脚本都会更改。一种简单但易出错的方法是在服务工作者脚本中包含version string内联。一种不易出错的方法是，只要对您正在缓存的基础资源进行更改，就会自动修改服务工作者脚本，以及sw-precache为您做的事情。在受控页面中，您可以listen for specific service worker lifecycle events并显示＆＃34;新内容可用;请刷新！＆＃34;消息等。