HTTP缓存机制详解：强缓存与协商缓存实战

引言

前端性能优化中，HTTP缓存是最直接、收益最大的手段之一。合理配置缓存策略，可以让用户在二次访问时几乎零网络开销地加载页面资源。本文结合实际排查经验，梳理强缓存与协商缓存的工作机制、常见坑点与排查方法。

一、两类缓存的基本分工

浏览器缓存分为强缓存与协商缓存两层。强缓存命中时，浏览器完全不发请求，直接从本地读取副本，控制字段是 Cache-Control 与 Expires；协商缓存则是在强缓存过期后，浏览器携带标识询问服务器资源是否变更，未变更返回 304，控制字段是 ETag/If-None-Match 与 Last-Modified/If-Modified-Since。

二、Cache-Control 关键指令

max-age 定义副本有效期（秒）；no-cache 不是不缓存，而是每次使用前必须协商校验；no-store 才是彻底不落盘；immutable 告诉浏览器资源永不变化，即使强缓存过期也不必发起协商请求，适合带内容哈希文件名的静态资源。

三、ETag 与 Last-Modified 的优先级

服务器同时下发两者时，浏览器校验优先使用 ETag。原因在于 Last-Modified 只能精确到秒，且无法表达"内容回滚"这类逻辑变更；ETag 是内容指纹，变更检测更可靠。实践中若 ETag 生成算法开销大（如全量哈希），可只保留 Last-Modified 换取校验效率。

四、常见坑点与排查思路

坑一：HTML 文件误配长 max-age，导致发版后用户长时间看到旧页面。正确做法是 HTML 用 no-cache，静态资源用带哈希文件名加长 max-age，实现"发版秒级生效 + 资源长缓存"。坑二：Nginx 默认按 mtime 生成 ETag，rsync 同步后 mtime 变化会导致全量缓存失效，可用 etag off 配合自定义缓存头。坑三：CDN 节点回源响应与源站头不一致，排查时要用 curl -I 分别对比源站与边缘节点的响应头。

五、验证方法

DevTools Network 面板中，Size 列显示 disk cache 或 memory cache 即强缓存命中；返回 304 表示协商缓存生效；Disable cache 勾选后可强制绕过缓存验证首次加载。建议每次调整缓存策略后，先用无痕窗口验证，再灰度观察真实用户的命中率曲线。

总结

缓存策略的本质是"变更成本与复用收益"的权衡：变更频繁的用协商缓存兜底，变更可预期的用哈希文件名加长强缓存。掌握这套模式后，绝大多数缓存类问题都能定位到具体环节。