第一次配缓存，先看响应头还是先改配置？

同事把浏览器开发者工具停在 Network 面板，第次指着一行 200 状态的配缓 logo.png 问：“我明明改了服务器上的图，用户刷新还是存先旧的，是看响不是缓存没做对？”我让他先把这一行点开，看 Response Headers 里有没有 Cache-Control。还先他翻了半天，改配说只有 Content-Type。第次这就是配缓第一次做缓存的人最常卡住的地方：还没确认响应头，就先跑去改 Nginx 配置。存先

先点开任意一条 200 请求，看响看清四个字段

不要凭印象判断“应该缓存了”。还先在浏览器里按 F12，改配切到 Network，第次刷新页面，配缓点一条静态资源请求，存先在 Headers 的 Response Headers 区域找这四项：Cache-Control、ETag、Last-Modified、Expires。它们决定浏览器下次是直接复用本地副本，还是回来问服务器。

常见的第一种卡点：只看到 Last-Modified，没有 Cache-Control。这时浏览器会按启发式规则自行估算缓存时长，行为不完全可控。第二种：Cache-Control 写的是 no-cache，有人以为“不缓存”，其实它是“可以存，但每次要验证”，跟 no-store 不是一回事。第三种：配置在 CDN 上生效了，但源站的响应头没变，你在本地怎么刷新都对不上。确认这四个字段，才知道问题出在源站、CDN 还是浏览器端。

在地址栏看那一把小锁，比猜配置快

改了响应头后，别急着重启服务。先在地址栏点开站点信息，或者用 curl 看原始响应：curl -I https://你的域名/静态文件路径，看返回头里 Cache-Control 是否已经变了。这一步能区分“配置没生效”和“配置生效但浏览器还拿着旧副本”。

浏览器端还有一个具体动作：在 Network 面板勾选 Disable cache，或者按住刷新按钮选“清空缓存并硬性重新加载”。注意，硬刷新只影响你这一台机器，用户那端仍然是旧副本。所以第一次做缓存，判断标准不是“我这边刷新看到新的了”，而是“响应头符合预期，且文件名或查询参数能让新版本走新地址”。

带哈希的文件名先改，再谈时长

第一次做浏览器缓存，最容易忽略的不是 max-age 填多少，而是资源文件名有没有版本标识。看打包产物：app.3f9a2c.js 这种带哈希的，可以放心给长缓存；logo.png、style.css 这种固定名字，给长缓存后用户很难拿到更新。判断标准很简单：打开构建目录，看文件名里有没有随内容变化的一串字符。

如果没有，先做两件事：要么在构建工具里开启文件名哈希，要么在引用时加 ?v=20240601 这类查询参数。做完再回头设置缓存时长。顺序反了，就会陷入“改了图用户看不到、只好让所有人强制刷新”的循环。这个顺序问题，比缓存参数本身更值得先确认。

用一条 curl 命令验证，再交给用户

配置改完，别只看自己的浏览器。在终端执行 curl -I 你的资源地址，对照三点：状态码是不是 200，Cache-Control 里 max-age 是否是你设的值，ETag 或 Last-Modified 是否存在。如果前面有 CDN，再对 CDN 域名执行一次同样的命令，确认边缘节点回源后头部一致。

发现不一致，下一步不是继续加参数，而是查清哪一层覆盖了响应头：源站应用、反向代理、CDN 控制台里的“缓存配置”页。很多第一次做缓存的人在这里卡住，是因为同时在三个地方改，改完不知道谁生效。建议一次只动一层，每动一次用 curl 复核。

最后提醒一个边界：涉及登录态、订单、个人中心这类接口，不要照搬静态资源的缓存策略。这类内容该由后端明确返回 no-store 或 private，拿不准就查对应框架和 CDN 厂商的官方文档，或者让后端同事确认。浏览器缓存做对的前提，是先分清哪些资源可以公开复用，哪些必须每次回源。