上下文：我有一个生产应用程序（如果要查看，则为here），该应用程序当前正在使用the gulp-rev-all package进行静态资产修订，与gulp-rev类似，除了它还在以下情况下处理依赖项时生成内容哈希。它会生成一组新的文件，这些文件具有静态名称（例如goals.js变为goals.6a5aa614.js），并使用这些静态名称相互引用。然后，我使用生产中的Fastly CDN来提供这些文件，因此我的NodeJS服务器没有被积极地用于静态资产。这一直很好。
现在，我正在与服务人员一起使网站脱机工作。自从去年我在同步逻辑方面做了很多工作以来，站点的动态部分已经非常容易检修。但是我对处理我的静态资产有点不知所措。
我认为我会使用Workbox，但这似乎还可以。但是workbox precache使用查询来破坏缓存，而不是更改文件名，这两者似乎很愚蠢。但是，如果我停止使用版本名称，那么如何在不支持Service Worker的浏览器上破坏缓存？
（我还有另一个相关的问题，考虑到Fastly的响应对于SW是不透明的，因此继续使用Fastly是否有意义，因此不一定是预缓存的好选择？对于不使用Service Worker的人来说，速度要慢很多，这听起来与PWA方法相反。我应该添加Nginx缓存或其他东西吗（我不知道这是什么，但我已经听过几次了）
在我看来，这必须有一个优雅的解决方案，但是我对gulp的理解非常有限，以至于我很难知道什么是可行的，并且我对ServiceWorkers和缓存的理解也足够有限的是，我很难确切地知道自己想要什么。
因此，我很难在这个问题上获得任何关注：
我如何调整gulp静态资产修订以与ServiceWorkers一起使用？
一件有用的事情仅仅是其他生产应用程序如何处理此示例的链接。
答案 0 :(得分：4)
服务工作者在良好的常规缓存策略之上表现最佳。您应该继续修改静态文件名，然后将其缓存在服务工作者中。避免使用通过查询字符串更改URL的库，因为您已经在修改URL，所以不需要该功能。
如果您的资产是从其他来源提供的（我想这就是您在快速讨论时的意思），然后允许通过CORS（通过Access-Control-Allow-Origin: *来请求它们，这意味着它们不会不透明。
答案 1 :(得分：2)
您应该保留文件修订的资产。有关使用gulp和预缓存的完整示例，请查看here。
您基本上想先使用缓存，然后再使用网络模式。您可以匹配/goals.*.js/ =>的请求，然后根据您的应用程序，即使[hash]不匹配，也可以决定使用缓存的Goals.js，然后下载新目标。[hash] .js在后台。
或者，如果哈希值不匹配，则您可能要先使用网络，然后回退到模糊匹配的Goals.js缓存中。
关于Nginx。通常建议对静态资产服务使用反向代理。 Node.js不适用于此任务。 example是一个很好的工作方法。如果进行此设置，那么静态资产的流程将如下所示：
CDN => <= Nginx => Node.js起源。
如果使用AWS。然后，使用Cloudfront CDN进行的典型设置将涉及将Nginx反向代理node.js EC2框设置为源。然后，您将为“ /”路由和“ / assets”路由设置行为。
“ /”行为可能具有较短的TTL，而“ // assets /”行为（Cloudfront中的路由）将具有您的长期（max-age = 3153600）缓存策略。
在这种情况下，几乎所有静态资产都将从CDN（Cloudfront）提供服务。当您使用一组新的文件修订资产部署新代码时，它仅需回到原始位置即可。
然后，您可以使用服务工作者非常快速地进行所有重复访问，甚至有可能在首次重复访问时使用过时的资产（匹配名称，不同的哈希），首先进行缓存，然后进行网络访问。这样，所有与服务工作人员重复使用的用户都将具有尽可能快的初始页面加载速度。
没有这些内容的人仍将获得文件修订的，具有CDN边缘服务的长期浏览器缓存资产的所有好处。