我正在构建一个反应应用程序，该应用程序包含在Amazon S3上的单页应用程序中。
有时候，我会同时在后端和前端部署一个更改，并且我需要所有浏览器会话才能开始运行新版本，或者至少那些会话在上一个前端之后开始的浏览器会话-结束部署。
发生的事情是，我的许多用户仍在其手机 上运行旧的前端版本达数周，而该版本与新版的手机背面不兼容-end结束，但是其中一些在开始下一个会话时得到更新。
当我使用Webpack来构建应用程序时，它会生成名称中带有哈希值的捆绑包，而定义了应使用的捆绑包的index.html文件是通过以下缓存控制属性上传的：{ {1}}。服务工作者文件具有相同的缓存策略。
这个想法是用户的浏览器可以缓存所有内容，并针对他们需要的第一个文件执行。该计划是好的，但是我用新版本替换了"no-cache, no-store, must-revalidate"文件，并且我的用户在重新启动应用程序时没有重新获取该文件。
是否有确定的指南或解决此问题的方法？
我也知道PWA应该脱机工作，因此它必须具有缓存以重复使用的能力，但是这个想法也无济于事，我不能执行大规模且即时的更新，对吗？
我要做的最好的选择是什么？
答案 0 :(得分：1)
您已经正确理解了基本概念。为什么不更新index.html是一个很难回答的问题，因为您没有提供任何代码-请提供您的Service Worker代码。请记住，根据Service Worker中实现的逻辑，它不一定遵循HTTP缓存标头，而是会缓存包括index.html文件在内的所有内容，就像现在正在发生的那样。
为了使应用程序也可以在脱机模式下工作，您可能需要使用 network-first SW策略。使用网络优先浏览器尝试从Web加载文件，但是如果失败，它将退回到它尝试获取的特定文件的最新缓存版本。另一种选择是选择一种“重新验证时失效”策略。这首先为用户提供了旧文件（速度极快），然后在后台更新了文件。还有其他策略，我建议您通读使用最广泛的SW库Workbox [https://developers.google.com/web/tools/workbox/modules/workbox-strategies]的文档。
要记住的一件事： 在除“跳过SW并转到网络”之外的所有其他策略中，您不能真正确保用户获得index.html的最新版本。这不可能。如果SW从缓存中退回某些内容，则可能是旧版本，仅此而已。在这些情况下，通常要做的是向用户通知已在后台下载了新版本的应用程序。基本上，用户将加载该应用程序，查看缓存中可用的版本，然后SW将检查更新。如果找到更新（有一个新的index.html，因此有一个新的service-worker.js），则用户将看到一条通知，告知您应刷新页面。如果需要，您还可以触发SW从您自己的JS代码手动检查服务器上的更新。在这种情况下，您也会向用户显示一条通知。
这对您有帮助吗？