HTTP 缓存分工：强缓存、协商缓存与版本化静态资源

缓存的目标不是“越久越好”，而是“该新的必须新，该省的必须省”。把三类机制分工用对，页面既能快，又不会让用户一直看到旧版本。

一、强缓存：命中时完全不发请求

强缓存由响应头控制，浏览器在有效期内直接用本地副本，不向服务器发请求，速度最快。

Cache-Control: max-age=31536000, immutable

max-age 单位是秒，immutable 表示资源在有效期内不会变，浏览器不必再验证。旧的 Expires 是绝对时间，受本地时钟影响，现在一般只作为兼容补充。

强缓存适合内容带版本标识的静态资源，例如文件名里带哈希的 JS、CSS 和图片。文件一改，文件名就变，旧缓存自然失效。

二、协商缓存：过期后再问一句“变了吗”

强缓存过期后，浏览器会带上验证信息向服务器确认，常用两组：

• ETag / If-None-Match：以内容摘要作为版本标识，内容不变返回 304，内容一变返回 200 和新资源。
• Last-Modified / If-Modified-Since：以最后修改时间判断，精度是秒，同一秒内多次修改可能判断不准。

304 响应没有正文，只省传输，不省一次往返。所以协商缓存适合“偶尔变、但不能错”的资源，例如 HTML 入口文件和接口响应。

三、版本化：让强缓存敢用长有效期

给静态资源加内容哈希是最稳妥的做法：

app.9f3a2c.js
main.b71d04.css
logo.e8c119.png

发布新版本时，HTML 里引用的文件名跟着变，用户必然拿到新资源；没变的资源文件名不变，继续命中强缓存。入口 HTML 本身不要设长缓存，一般用 no-cache，即每次都要协商验证，确保拿到最新的引用关系。

四、一张决策表

五、常见坑

1. 给 HTML 设了长 max-age：发布后用户迟迟看不到新版，只能等缓存过期或手动清缓存。
2. 只用 Last-Modified：同一秒内改动、或文件被重新打包但内容相同，都可能误判。
3. 忘记版本化就拉长缓存：文件名不变时，强缓存会把旧资源一直用到过期。
4. 把 no-cache 理解成“不缓存”：no-cache 是“每次用前先验证”，真正完全不存的是 no-store。

六、上线前检查清单

• 入口 HTML 是不是 no-cache，引用的是不是最新哈希文件名。
• 静态资源改动后文件名是否真的变了。
• 服务器是否正确返回 ETag，304 是否不带正文。
• CDN 或反向代理有没有覆盖源站的缓存头。

分工清楚之后，缓存就不再是“快还是新”的二选一：不变的资源放心缓存长一点，会变的资源靠协商和版本化兜底，两者配合，页面才能又快又准。