静态网页更新后还是旧版本，先分清是谁在缓存

网页明明上传了新文件，打开却还是旧内容。这时候先别反复刷新，至少有三种可能：浏览器用了本地副本，CDN还在返回旧响应，或者新文件根本没传到正在访问的目录。

先打开浏览器开发者工具的Network面板，检查请求的完整URL，以及响应头里的 Cache-Control、ETag 和 Last-Modified。也可以在终端查看一次普通GET请求的响应头，下面的域名只是示例：

curl -sS -D - -o /dev/null https://example.com/

强制刷新可以帮助排查浏览器缓存，但不能单凭它判断源站和CDN都已经更新。尤其是接入CDN的站点，浏览器即使重新请求，也可能拿到边缘节点保存的旧文件。

不是所有静态站点都有CDN。没有接入就不用查这一层；已经接入的，可以结合服务商的命中响应头、缓存规则和刷新记录判断。确认是边缘缓存后，再针对相关URL做失效或等待过期，不必一上来清空整个站点。

如果新旧内容依然对不上，回到上传环节看一眼：构建产物是不是最新的，远端目录对不对，域名是否绑定了另一个桶或站点，路径大小写有没有变化。允许访问源站时，对比源站和公开域名返回的内容，通常比盯着“上传成功”四个字更有用。

缓存策略可以把入口文件和静态资源分开考虑。index.html里保存着脚本、样式等资源的地址，它一旦长期不更新，后面的文件即使发了新版，也可能没人请求。对经常变化的入口，可以考虑：

Cache-Control: no-cache

这个名字很容易误导人。no-cache并不是禁止保存副本，而是复用前要向服务端重新验证，通常配合 ETag 或 Last-Modified 使用。服务端确认没有变化时，可以返回304，不必重新发送完整内容。no-store才是要求缓存不要保存这份响应，不能把两者当成同一个开关。

脚本和样式则可以反过来处理。构建时把内容哈希写进文件名，例如 app.8f31c.js；内容变了，文件名也跟着变，同时更新HTML里的引用。只要这些URL下的文件确实不再改变，就可以设置较长的 max-age，并按需要使用 immutable。

这套办法的关键不只是“文件名带一串字符”，而是新内容必须使用新URL。已经发布的旧资源也别立刻删除，旧页面或尚未刷新的浏览器可能还会请求它们。如果整个页面只有一个内联脚本的HTML文件，就先把这个入口文件的重新验证做好，不必为了缓存策略强行拆文件。

看到旧页面时，先确认请求到了哪份HTML，再看它引用了哪些资源，最后沿着实际部署链路查缓存。把文件和URL对上，往往比让所有人清浏览器记录更管用。

参考：MDN：HTTP缓存（https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching）、Cloudflare：缓存重新验证（https://developers.cloudflare.com/cache/concepts/revalidation/）。这些资料解释通用缓存行为，不代表站点已经使用了某家CDN。

写作说明：本文由AI辅助起草，命令中的域名为示例。