第五步：什么情况下，浏览器会受哪个头影响

本节目标：理解“第五步：什么情况下，浏览器会受哪个头影响”的核心思路，并能把它用于实际开发或面试表达。 场景 1：普通首次访问 浏览器没有本地缓存条目，就发普通请求。返回后，是否存、存多久，由响应头里的 Cache-Control / Expires / 状态码可缓存性决定。若以后要做重验证，还要看这次响应有没有 ETag / Last-Modified。(RFC Editor) 场景 2：普通再次访问，且缓存仍 fresh 浏览器直接复用本地缓存，不需要发 If-None-Match / If-Modified-Since。fresh 的判断主要看 Cache-Control: max-age、Expires、Age。(RFC Editor) 场景 3：缓存 stale，但响应带 ETag 浏览器通常会带 If-None-Match 去重验证。服务端返回 304，浏览器继续用本地实体；返回 200，则替换成本次响应。(MDN Web Docs) 场景 4：缓存 stale，没有 ETag，但带 Last-Modified 浏览器通常会带 If-Modified-Since。服务端若认为未修改，回 304；否则回新内容。(MDN Web Docs) 场景 5：响应是 no-cache 即使缓存没过期，也不能直接复用；每次都要重验证。这里最容易看到“本地有缓存，但仍然每次都发请求”的现象。(MDN Web Docs) 场景 6：响应是 no-store 浏览器不该留下缓存条目；下一次访问通常只能重新请求。(MDN Web Docs) 场景 7：资源带 hash，且 max-age 很长，外加 immutable 浏览器在 fresh 窗口内可以非常激进地复用，不必在刷新时多做没必要的条件请求。这是现代静态资源最推荐的姿势。(MDN Web Docs) 场景 8：用户普通刷新页面 浏览器通常会带 Cache-Control: max-age=0；也可能结合验证器发条件请求。它不是“清空所有缓存”，而是更偏向“重新确认是否最新”。(MDN Web Docs) 场景 9：用户强制刷新 浏览器通常会带 Cache-Control: no-cache，要求先验证再复用；实际资源是否重新下载，还要看服务端是否回 304 还是 200。(MDN Web Docs) 场景 10：fetch(url, { cache: ... }) 这时优先看 Request.cache 模式，而不是只看服务端响应头。也就是说，你的 JS 代码可以把浏览器的默认缓存决策改掉。(MDN Web Docs) 场景 11：Service Worker 已接管 这时真正的“先查什么、再查什么”由 Service Worker 决定。它可能先用 Cache API，也可能完全不理 HTTP cache。(MDN Web Docs) 场景 12：用户点浏览器后退/前进 如果页面满足条件，浏览器优先可能直接从 bfcache 恢复整页。这个场景下，你看到的是“页面瞬间回来”，不是一次普通的 HTTP cache 命中。(MDN Web Docs)