progressive-web-apps - 使用 Service Worker 进行预缓存，为什么重要？我错过了什么？

Question

我正在研究服务 worker 的做法和 workbox .
有很多文章在谈论预缓存，workbox 甚至提供了特殊的方法 precachingAndRoute() 仅此而已。我想我理解 precache 和运行时缓存之间的概念区别，但让我困惑的是为什么 precache 被如此特殊对待？
我读过的所有关于预缓存的文章都强调了它如何在客户端离线时使 Web 应用程序可用。这不是缓存(即使它不是预缓存)的用途吗？我的意思是，如果配置正确，运行时缓存似乎也可以实现这一点。是否必须预先缓存才能让 Web 应用程序脱机工作？
唯一明显的区别是创建缓存的时间。那么，如果客户端离线，则无法创建缓存，无论是预缓存还是运行时缓存，如果缓存是在客户端在线时上次访问期间创建的，那么当前访问响应的缓存是否为预缓存或运行时缓存？
考虑 2 个抽象案例进行比较。假设我们有两个不同的 Service Worker，一个( /precache/sw.js )只做预缓存，另一个( /runtime/sw.js )只做运行时缓存，其中 /precache和 /runtime托管相同的 Web 应用程序(意味着要缓存的相同 Assets )。
在什么场景下，web app /precache和 /runtime由于不同的软件设置，可能会以不同的方式运行？
在我的理解中，

如果无法创建缓存(例如第一次访问时离线)，则预缓存和运行时缓存应该没有任何不同。

如果可以成功创建预缓存(即客户端在线
第一次访问)，运行时缓存也应该。 (让我们不要太狂野
像客户端可能只在线一段时间的情况，在我的例子中它们仍然应该是相同的。)

如果缓存可用，则预缓存和运行时缓存无关，因此仍然相同。

当 precache 显示出优势时，我能想到的唯一情况是需要在当前访问时更新缓存，其中 precache 确保当前访问获得最新信息。如果是这种情况，NetworkFirst 运行时缓存会不会做同样的事情？而且，与“离线”无关，我读过的几乎每篇关于 sw 预缓存的文章都会提到。
在线/离线如何使预缓存成为英雄？
我在这里错过了什么，预缓存有什么特别之处？

Answer 1

首先，您的并排服务人员仅限于这些文件夹或路径。所以他们彼此隔离。
其次，您应该为您的应用程序定义一个缓存策略，该策略包含 preCached Assets 以及动态和失效例程/逻辑的混合。
您希望在不破坏应用程序的任何动态特性的情况下尽可能多地预缓存。所以缓存常用的JS、CSS、图片、字体和反复使用的页面。
当然，要有一个失效策略来使这些保持最新。
接下来处理来自 fetch 事件处理程序的非缓存网络可寻址资源 (URL)。缓存它们，因为它是有道理的。并使缓存 Assets 无效，因为它是有道理的。
对于某些应用程序，我缓存了整个内容。它们通常很小，例如几十到几百页。对于像亚马逊这样的网站，我永远不会这样做，哈哈。无论缓存了多少，我总是有一个对应用程序/站点有意义的失效和更新策略。