Cloudfront缓存失效时，stale-while-revalidate为何未生效？如何软清除？

核心结论 #

• stale-while-revalidate（SWR）仅在缓存的max-age（或s-maxage）过期后才会生效，主动执行缓存失效（比如调用CloudFront的Invalidation API）会直接删除缓存条目，此时SWR机制无法触发——因为缓存已经不存在了，自然没有“陈旧内容”可以返回。
• CloudFront本身没有原生的“软清除”功能，但可以通过替代方案实现类似效果。

问题原因分析 #

你配置的缓存头：

max-age=1800, public, s-maxage=3600, stale-if-error=3600, stale-while-revalidate=600

当主动执行缓存失效后，CloudFront会立即删除对应URL的缓存副本。此时并发请求过来时，CDN会直接回源拉取新内容，期间所有请求都会等待源站响应，导致大量流量打向源站，这和你观察到的现象一致。

SWR的生效逻辑是：缓存条目存在但已过max-age时，CDN先返回陈旧内容给用户，同时异步回源刷新缓存。但主动失效会直接删除缓存，跳过了“缓存过期但仍存在”的阶段，所以SWR无法发挥作用。

实现类似“软清除”的方案 #

• 版本化URL：不要直接对原有URL执行失效，而是更新内容后使用新的URL（比如在资源路径或参数中加入版本号，如/image.jpg?v=2）。原有URL的缓存可以自然过期，新URL直接缓存新内容，完全避免回源风暴。
• 利用Cache-Control的must-revalidate配合SWR：如果必须使用同一URL，不要主动执行缓存失效，而是在更新内容后，让CDN的缓存自然过期。当缓存过了s-maxage后，SWR会自动触发，先返回旧内容再异步刷新。如果需要更快更新，可以缩短s-maxage的时长，同时保留SWR配置。
• 使用CloudFront的Cache Policies自定义缓存行为：创建缓存策略时，确保SWR参数正确配置，同时避免主动失效操作。如果必须触发更新，可以考虑使用CloudFront的Origin Request Policy添加自定义头部，让源站识别需要刷新的请求，但这种方式需要源站配合处理。

补充说明 #

启用Origin Shield后仍出现大量回源，是因为缓存失效后Shield层也没有缓存副本，所有请求会穿透到源站。只有当缓存条目存在（哪怕过期）时，Shield层才会利用SWR机制，只发起一次回源请求，同时返回旧内容给边缘节点。

内容的提问来源于stack exchange，提问作者Nick