新服务工作者的sw-precache激活是否保证缓存中断？

Question

我使用sw-precache和sw-toolbox一起允许离线浏览角度应用程序的缓存页面。

该应用程序通过节点快速服务器提供服务。

我们遇到的一个问题是，index.html有时似乎没有在缓存中更新，尽管在激活新的服务工作人员时已经更新了其他资产。

这给用户留下了一个过时的index.html，它试图加载的不再是现有的版本化资产，在本例中是/scripts/a387fbeb.modules.js。

我不完全确定发生了什么，因为在不同的浏览器上，如果index.html已经正确更新了，就会有相同的哈希。

在一个浏览器上过时(有问题)的Index.html

(用2cdd5371d1201f857054a716570c1564哈希缓存)包括：

<script src="scripts/a387fbeb.modules.js"></script>

在内容上。(此文件不再存在于缓存中或远程中)。

在另一个浏览器上更新(好的) index.html

(用相同的2cdd5371d1201f857054a716570c1564__缓存)包括：

<script src="scripts/cec2b711.modules.js"></script>

尽管返回到浏览器的内容是不同的，但这两者的缓存是相同的！

我该怎么看这个？这是否意味着当新SW激活时，sw-precache不保证原子缓存崩溃？如何才能保护自己不受此影响？

如果这些帮助，这是来自sw-precache的sw-precache文件。

Note：我意识到我可以使用remoteFirst策略(至少对于index.html)来避免这种情况。但我仍然想了解并想出一种使用cacheFirst策略来充分利用性能的方法。

备注2：我在其他相关问题中看到，可以更改缓存的名称以强制关闭所有旧缓存。但这似乎超越了sw-precache只破坏更新内容的想法？这是该走的路吗？

备注3：注意，即使我很难重新加载网站被破坏的浏览器。该站点将工作，因为它将跳过服务工作者缓存，但缓存仍然是错误的-服务工作者似乎没有激活-我猜是因为这个特定的SW已经激活，但未能正确地破坏缓存。随后的非硬刷新访问仍然会看到损坏的index.html。

Answer 1

(这里的答案是特定于图书馆的。这些细节一般不适用于服务工作者，但有关缓存维护的概念可能仍然适用于更广泛的受众。)

如果index.html的内容是由服务器动态生成的，并且依赖于内联或通过<script>或<link>标记引用的其他资源，那么您需要通过dynamicUrlToDependencies选项指定这些依赖项。下面是作为库的一部分提供的一个示例app-shell-demo：

dynamicUrlToDependencies: {
  '/shell': [
    ...glob.sync(`${BUILD_DIR}/rev/js/**/*.js`),
    ...glob.sync(`${BUILD_DIR}/rev/styles/all*.css`),
    `${SRC_DIR}/views/index.handlebars`
  ]
}

(这里使用的是/shell，而不是/index.html，因为这是用于访问缓存的App的URL。)

此配置告诉sw-precache，每当任何与这些模式匹配的本地文件发生变化时，动态页面的缓存条目都应该被更新。

如果您的index.html不是由服务器动态生成的，而是在构建时使用类似这种方法的内容进行更新，那么重要的是要确保运行sw-precache的构建过程中的步骤发生在所有其他修改和替换发生之后。这意味着使用类似于run-sequence的方法来确保服务工作者生成不会与其他任务并行运行。

如果上面的信息对你没有帮助，可以通过提出一个错误获得更多的细节，包括你网站的网址。