HTTP缓存怎么用才不踩坑：强缓存与协商缓存配合实战

打开一个网页很快，第二次打开更快，往往不是网络变好了，而是缓存起了作用。缓存用得好，能省带宽、降延迟；用得不好，最常见的就是：明明已经上线了新版本，用户看到的还是旧页面。下面把强缓存和协商缓存讲清楚，再给一套可以直接照抄的搭配方法。

一、浏览器缓存的是什么

浏览器第一次请求图片、样式、脚本等资源时，会把响应和它的缓存规则一起存下来。下一次再请求同一个地址，浏览器先看本地有没有、过期没有，而不是每次都去问服务器。注意这里的判断依据是地址加缓存头，不是文件名看起来像不像。改了内容却不改地址，又不给合理的缓存时间，就很容易出现旧版本阴魂不散。

二、强缓存：不发请求，直接用本地的

强缓存由 Cache-Control 控制，常见写法是 max-age=31536000，表示一年内直接用本地副本，不用再请求服务器。Expires 是老写法，用的是绝对时间，容易受客户端时钟影响，现在一般只用 Cache-Control 就够了。强缓存适合内容基本不变、而且文件名带哈希的静态资源，例如 app.9f3c.js。文件名一变，地址就变，旧缓存自然失效，不用担心用户拿到旧文件。

三、协商缓存：先问服务器，有没有变

如果强缓存过期，或者响应头写了 no-cache，浏览器会带着条件去问服务器。Last-Modified 对应 If-Modified-Since，是按最后修改时间判断；ETag 对应 If-None-Match，是按内容指纹判断。服务器发现没变，返回 304，不带正文，省流量；发现变了，返回 200 和新内容。ETag 更精确，能识别一秒内多次修改、内容回滚等时间戳看不出来的变化，所以关键资源优先用 ETag。

四、推荐搭配：入口和静态资源分开对待

最稳妥的分工是：HTML 入口文件不做强缓存，或者只给很短的 max-age，让浏览器每次都去协商确认；图片、样式、脚本等静态资源用长 max-age 加内容哈希。这样既保证新版本能及时到达用户，又让不常变的文件一次下载、长期复用。发布时只改入口引用的哈希文件名，旧文件可以继续被缓存，不会互相干扰。

五、排查时先看这三点

第一，看响应头到底写了什么，不要凭感觉猜缓存时间；第二，看状态码是 200 还是 304，确认走的是强缓存、协商缓存还是根本没缓存；第三，确认是不是 CDN 或代理层又加了一层缓存，源站改了，边缘节点还没回源。本地调试时可以用无痕窗口或禁用缓存，避免被自己的缓存误导。

缓存不是越久越好，也不是越短越安全。把入口文件做短、把带哈希的静态文件做长，再用 ETag 兜底一次变化判断，多数线上旧版本问题都能提前避免。