S3+CloudFront静态网站：强制浏览器获取新资源的推荐方案

这确实是静态网站部署后常见的头疼问题——CloudFront的缓存失效了，但浏览器本地还攥着旧资源不放。我结合AWS生态的最佳实践，给你几个靠谱的解决方案，按推荐优先级排序：

1. 版本化资源文件名（最推荐的长期方案） #

浏览器的缓存逻辑核心是基于URL识别资源，只要资源文件名变了，浏览器就会判定这是全新资源，直接发起新请求。这个方法不仅能彻底绕过浏览器缓存问题，还能最大化利用CDN和浏览器的缓存能力，减少不必要的重复请求。

具体操作：

• 给静态资源（JS、CSS、图片等）添加内容哈希后缀，比如把style.css改成style.abc123.css，app.js改成app.def456.js。主流构建工具（Webpack、Vite、Parcel等）都支持自动生成这种哈希后缀，完全不用手动修改。
• 在HTML文件中引用这些带哈希的资源文件名。
• 给带哈希的资源设置超长缓存时间（比如Cache-Control: public, max-age=31536000, immutable），因为只要内容不变，哈希就不会变，浏览器可以放心缓存一整年；而HTML文件作为入口，设置较短的缓存策略（比如Cache-Control: no-cache, must-revalidate），确保用户每次访问都能拿到最新的HTML，进而加载最新的资源。

2. 优化Cache-Control响应头 #

针对不同类型的资源配置精准的缓存策略，平衡缓存效率和更新及时性：

• HTML文件：设置Cache-Control: no-cache, must-revalidate，浏览器每次都会向CloudFront验证HTML是否有更新，若有则拉取新文件。
• 版本化的静态资源：设置Cache-Control: public, max-age=31536000, immutable，immutable指令会告诉浏览器该资源永远不会改变，无需再发起验证请求，最大化缓存性能。
• 未版本化的静态资源（不推荐长期使用）：设置较短的max-age，比如max-age=86400（1天），让浏览器每天自动更新一次资源。

配置方式：可以直接在S3控制台给文件设置元数据，或者在CloudFront的缓存策略中按路径匹配（比如/*.html和/*.css分别设置不同策略）统一配置。

3. 查询参数临时应急（不推荐长期使用） #

如果不想修改文件名，临时更新资源时，可以给资源URL添加查询参数，比如app.js?v=2。浏览器会把带不同参数的URL视为不同资源，从而请求新版本。

注意事项：

• 需在CloudFront的行为设置中，将「缓存键和源请求」里的「查询字符串」设为「全部包含」，否则CloudFront会忽略查询参数，依然返回旧缓存。
• 这个方法的局限性：查询参数可能被部分缓存系统忽略，且无法像内容哈希那样精准对应资源内容（比如你手动改了v值但内容没变化，也会触发新请求），所以只适合临时应急，不建议作为长期方案。

4. 兜底：确保HTML缓存及时更新 #

HTML是所有资源的入口，只要HTML能及时更新，用户就能加载到最新的资源链接。部署后可以针对性地失效HTML的CloudFront缓存：

aws cloudfront create-invalidation --distribution-id YOUR_CLOUDFRONT_ID --paths "/index.html" "/*.html"

同时配合HTML的no-cache缓存策略，双管齐下确保入口文件的新鲜度。

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