我最近使用 Cloud Functions 和 Firebase Hosting 实现了 SSR。
当 JS 包构建时，它会收到一个缓存突发后缀（main.1.js).
在我的函数内部，我有以下代码段用于缓存云函数的结果
res.set('Cache-Control', 'public, max-age=300, s-maxage=300');
在部署过程中，我先部署托管，然后部署云功能
firebase deploy --only hosting:production && gcloud functions deploy ssr --runtime nodejs8 --trigger-http --source dist/server
firebase 托管部署取代main.1.js with main.2.js.
由于缓存爆破，文件现在不同了（main.2.js）但是因为云函数又缓存了 5 分钟 - 当我访问网站时出现错误（因为main.1.js该函数的缓存版本中引用的内容不再可用）。
你会如何解决这样的问题？我可以有两个活动部署并依次激活吗？
缓存控制头public, max-age=300, s-maxage=300告诉处理请求的任何一方（主要是用户的浏览器和 Google 的 CDN 服务器，但也可以是用户正在使用的代理）如何缓存请求。根据您的配置，两者都会将文件缓存 5 分钟。您无法更改此行为，因为无法使 CDN 服务器的缓存失效，并且浏览器也不知道您的部署，即使它会收到通知并重新加载，也会从 CDN 获得相同的过时文件。
我不完全理解您的用例，但以下是可能的解决方案：
- 确保不要删除旧文件，因此您需要保留任何版本
main.x.js至少在缓存持续时间内。您可以使用 Cloud Storage 在部署时上传文件。
- 向客户端添加后备。如果
main.1.js给出 404，增加数字并尝试main.2.js
- 保持名称稳定，例如
main.js
- 添加内容
main.js到云函数的响应主体。通过这样做，您可以确保云功能响应和内容main.x.js一起缓存并一起重新加载
- 删除缓存控制标头。这将导致您的功能流量增加，从而导致成本增加。
- 还可以更改函数名称或其在部署时重写以导致缓存未命中
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
