AWS Cloudfront缓存配置：浏览器缓存1年但每24小时重新验证如何实现

现有配置评估 #

你当前给出的缓存配置无法满足「每24小时重新验证」的需求，核心问题是参数逻辑存在冲突：

• max-age=31536000定义了资源的本地新鲜期为1年，这段时间内浏览器发起请求会直接调用本地缓存，不会向CDN发起任何验证请求，和24小时验证的要求完全矛盾。
• must-revalidate的作用是缓存过期后必须回源校验，不能直接使用过期资源，搭配1年的max-age等于1年内都不会触发该规则，完全无法发挥作用。
• stale-while-revalidate=6800仅定义了约1.9小时的stale宽限期，只有max-age到期后才会生效，在当前配置下没有实际意义。

推荐配置方案 #

符合你需求的缓存头配置如下：

cache-control: public, max-age=86400, stale-while-revalidate=31449600, must-revalidate

各参数逻辑完全匹配你的需求：

• max-age=86400：设置24小时的本地新鲜期，这段时间内浏览器直接使用本地缓存，无额外请求产生。
• stale-while-revalidate=31449600：该数值为1年总秒数减去24小时的秒数，代表24小时新鲜期结束后的1年内，用户访问资源时可以先返回旧缓存内容不影响加载速度，同时后台异步向Cloudfront发起验证请求检查资源是否更新，天然满足你每24小时后重新验证的要求。
• must-revalidate：总缓存时长满1年后，浏览器不能再使用旧缓存，必须回源拉取最新资源，满足最长缓存1年的要求。
• 无需额外添加proxy-revalidate参数，Cloudfront作为CDN代理默认遵循配置规则，额外添加反而可能导致部分公共代理出现不必要的验证逻辑。

发布流程适配说明 #

你现有的Travis触发Cloudfront缓存失效的流程完全可以搭配上述配置使用：

• 每月更新资源后下发缓存失效命令，Cloudfront节点会拉取最新资源，后续浏览器发起的验证请求就会拿到最新版本，不会出现缓存遗留问题。
• 如果你对24小时的验证精度要求不高，也可以根据实际情况将max-age调整为12小时到36小时区间内的数值，只要低于每月的更新频率都不会产生问题。

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