当我推送新网站时，我会更新 Origin ID 以指向新版本，如屏幕截图所示：
这反过来又触发了状态从已部署到进行中在主 CF Distributions 控制台上。我的理解是，这不是触发边缘缓存的实际失效。这是否意味着我必须等待状态再次改变才能已部署在我触发失效之前？如果是这样，那么对于任何自动化部署来说，这都是一个可怕的依赖关系。我想它必须不断检查，直到部署状态显示完成，然后触发失效。
简而言之，为什么要更新 CF 的源路径这么慢？
如果有更好的方法来部署一个在 S3/CF 中有索引页的新网站，我洗耳恭听 :)
答案1
使用资产版本控制。
您的网站的 V1 将引用/v1/js/app.js，/v1/img/logo.png， ETC。
当你推送新版本时，它将引用/v2/js/app.js，/v2/img/logo.png， ETC。
这样，客户仍然需要参考v1由于某些缓存内容，资产可以这样做，并且不会因失效而中断。新访客将获得全部-v2内容，不会被任何v1到处都是东西。
最终一天后，你可以删除并使其无效v1，但这不是一个时间敏感的任务。
当然，您不必使用 v1、v2 等，如果您愿意，可以使用 git hash 或者 date 或其他内容。
更新：正如@Michael-sqlbot 在评论中指出的那样根对象返回“GET /”是一种特殊情况，因为它不会从这种基于路径的版本控制中受益。您有几个选择：
为根对象设置一个较短的过期时间，例如 5 分钟。这样，它将在您上传新网站版本后不久自动过期。
或者上传新版本并使其无效
/index.html- 这比使数千个文件资产无效要快得多，也便宜得多。
在这两种情况下，从所有 CloudFronts 上传 V2 和过期 V1 之间会有短暂的重叠，/index.html但没关系因为所有 V1 资产仍然可用。无论您的访问者在此期间收到 V1 还是 V2 index.html，他们仍将获得一个可正常运行的网站。
希望有帮助:)