HTTP 缓存入门：强缓存与协商缓存怎么配合

打开一个网页时，浏览器并不是每次都重新下载所有资源。HTTP 缓存就是让浏览器在合理条件下复用已下载内容，从而减少请求、加快打开速度、减轻服务器压力。理解缓存，关键是分清强缓存和协商缓存：前者不发请求直接用本地副本，后者先问服务器内容有没有变，再决定用旧的还是下载新的。

强缓存由响应头控制。最常用的是 Cache-Control，例如 max-age=3600 表示资源在 3600 秒内可以直接复用，不需要向服务器确认。no-cache 并不等于不缓存，它的意思是每次使用前必须先向服务器验证；no-store 则表示完全不要存，适合包含敏感信息的响应。Expires 是较老的写法，用一个绝对时间表示过期时刻，容易受客户端时钟影响，现在一般以 Cache-Control 为准。

强缓存过期后，协商缓存登场。服务器可以在响应中带上 ETag，也就是资源的版本标识，通常由内容生成；浏览器下次请求时带上 If-None-Match，如果标识一致，服务器返回 304 Not Modified，浏览器继续用本地副本。另一组是 Last-Modified 与 If-Modified-Since，用最后修改时间判断，但时间精度只有秒，内容改了时间没变时可能判断失误，因此 ETag 更可靠。304 响应没有正文，只是一次轻量确认，比重新下载划算得多。

一次典型流程是这样的：首次访问下载图片并存入缓存，响应写明 max-age=86400，同时带 ETag；一天内再次访问，强缓存命中，直接展示，不发请求；过期后浏览器带 If-None-Match 询问，服务器发现内容未变，返回 304，浏览器继续用旧图；如果图片已更新，服务器返回 200 和新内容，浏览器替换缓存。整个过程对用户几乎无感，却省下了大量重复传输。

实际使用中还有几个容易踩的坑。第一，HTML 入口文件一般不要设很长的强缓存，否则发了新版用户仍看到旧页面；常见做法是入口文件用 no-cache 或较短时间，静态资源用带内容哈希的文件名加长期缓存，内容一变文件名就变，自然失效。第二，登录后才能看的数据、订单、余额等动态接口不要轻易缓存，避免 A 用户看到 B 用户的数据。第三，CDN 和代理也可能缓存响应，调试时要分清是浏览器缓存、CDN 缓存还是服务器本身没更新。

给自己一个落地清单：静态图片、样式和脚本按内容哈希命名并设长期缓存；入口 HTML 保持可验证；接口默认不缓存，需要缓存时明确写清适用范围和失效条件；上线后用浏览器开发者工具看请求是 200、304 还是直接来自磁盘缓存，再确认策略是否生效。缓存不是越久越好，也不是越短越安全，配合得当，才能在速度和新鲜度之间找到平衡。