每次部署后按路径刷新 CDN 缓存

只失效发生变化的入口路径，等待失效完成，并在边缘验证新 HTML 已生效，避免全量刷新拖垮源站。

概述

刷新缓存是修复手段，不是部署步骤。如果每次部署都全量失效，源站会迎来流量尖峰，边缘缓存变冷，用户延迟恰好在版本最不可信的时候上升。更好的设计是让带内容哈希的静态资源缓存一年，HTML 使用较短缓存，这样部署只需要失效发生变化的入口文件。刷新因此变得范围小、可预测，也快到可以在流水线中等待完成。

步骤

只失效变化的入口路径：

aws cloudfront create-invalidation \
  --distribution-id E123456 \
  --paths "/index.html" "/docs/*"

等待失效完成后再执行冒烟测试：

INVALIDATION_ID=$(aws cloudfront create-invalidation \
  --distribution-id E123456 --paths "/index.html" \
  --query 'Invalidation.Id' --output text)
aws cloudfront wait invalidation-completed \
  --distribution-id E123456 --id "$INVALIDATION_ID"

在边缘验证内容已更新：

curl -sI https://app.example.com/index.html | grep -iE 'x-cache|age|etag'

保持失效路径数量很少，静态资源依赖内容哈希自动换名。

验证

x-cache 应显示 miss 或 refresh hit，age 接近 0，ETag 与新构建一致。HTML 中的资源引用应指向新的哈希文件名，旧文件仍可从缓存命中。若边缘仍返回旧页面，应检查是否存在第二层缓存、反向代理或 Service Worker。冒烟测试必须在失效完成后执行，否则可能命中仍有旧内容的边缘节点，得到假失败或假通过。

注意事项

失效是最终一致的，即使报告完成也可能需要数分钟才在所有边缘生效。
刷新无法修复错误的 Cache-Control，下一次响应仍会按同样的错误策略缓存。
通配符失效有并发限制，滥用会被限流。
静态资源使用内容哈希后无需刷新，删除旧文件前要留足缓存周期。
浏览器缓存与 CDN 缓存是两层，CDN 刷新不影响本地缓存。