Context：我有一个生产应用程序(如果你想看的话，这里)，它目前正在使用gulp-rev-all包进行静态资产修订，该包与gulp-rev类似，只是它在生成内容哈希时也处理依赖关系。它生成一组新的文件，这些文件具有静态名称(例如goals.js变为goals.6a5aa614.js)，并使用这些静态名称相互引用。然后我在生产中使用Fastly CDN提供这些文件，所以我的NodeJS服务器没有被积极用于静态资产。这一直很有效。
现在，我正在让网站与服务人员离线工作。自从去年我在同步逻辑上做了很多工作以来，这个网站的动态部分很容易检修。但我有点不知所措，不知道该怎么处理我的静态资产。
我想我会用工作簿，这似乎还可以。但是workbox precache使用查询来破坏缓存，而不是更改文件名，而且两者都做似乎很愚蠢。但是，如果我停止使用版本化的名称，那么我如何在不支持service worker的浏览器上破坏缓存？
(我还有一个相关的问题，那就是考虑到Fastly的响应对软件来说是不透明的，因此不一定是一个好的预处理选项，继续使用Fastly有意义吗？尽管没有Fastly，对于那些不使用服务人员的人来说，应用程序会变得慢得多，这听起来与PWA方法相反。我应该添加nginx缓存还是其他什么？(我不知道这是什么，但我听说过几次)
在我看来，必须有一个优雅的解决方案，但我对gulp的理解非常有限，我很难知道什么是可能的，我对ServiceWorkers&缓存非常有限，我很难确切地知道我想要什么。
因此，我很难在这个问题上获得任何吸引力：
如何调整我的静态资产修订以与ServiceWorkers一起工作
有一件事会很有帮助，那就是链接到其他生产应用程序如何处理这一问题的示例。
服务工作者在良好的常规缓存策略之上工作得最好。您应该继续修改静态文件名，然后将它们缓存在服务工作者中。避免使用通过查询字符串更改URL的库，因为您已经在修改URL，所以不需要该功能。
如果您的资产是从另一个来源提供的(我想这就是您谈论Fastly时的意思)，那么允许通过CORS(通过Access-Control-Allow-Origin: *)请求它们，这意味着它们不会不透明。
您应该保留经过修订的文件资产。关于使用gullow和preching的完整示例，请看这里。
您基本上想先使用缓存，然后使用网络模式。您可以将请求匹配到/targels.*.js/=>，然后，根据您的应用程序，即使[哈希]不匹配，您也可以决定使用缓存的goals.js，然后下载新的目标。后台的[hash].js。
或者，如果散列不匹配，你可能想先使用网络，回退到goals.js.的模糊匹配缓存
至于Nginx。通常建议对静态资产服务使用反向代理。Node.js不适合执行此任务。这是一个很好的工作示例。如果你采用这种设置，你的静态资产流将如下所示：
CDN=>=Nginx=>Node.js原点。
如果您使用AWS。然后，Cloudfront CDN的典型设置将包括将Nginx反向代理node.js EC2框设置为原点。然后，您将为"/"路由和您的"/assets"路由设置一个行为。
"/"行为可能具有较短的TTL，而"/assets/"行为(Cloudfront中的路由)将具有长期(最大年龄=3153600)缓存策略。
在这种情况下，几乎所有静态资产都将由CDN(Cloudfront)提供服务。当您使用一组新的文件修订资产部署新代码时，它只需要返回到您的源代码。
然后，您可以使用服务人员快速完成所有重复访问，甚至可能在初次重复访问时使用过时的资产(匹配的名称、不同的哈希)，方法是先缓存，然后网络。因此，具有服务工作者的所有重复用户将具有尽可能快的初始页面加载。
那些没有CDN边缘服务的用户仍然可以获得文件修订、长期浏览器缓存资产的所有好处。