浏览器缓存命中却仍请求服务器：强缓存与协商缓存排查

浏览器“命中缓存”却仍然看到服务器请求，通常不是缓存失效，而是把两种命中混在了一起：资源还新鲜时，浏览器可以直接复用，服务器完全收不到请求；资源已经过期但仍有校验信息时，浏览器会带上 If-None-Match 或 If-Modified-Since 回服务器确认，服务器返回 304 Not Modified，浏览器继续使用本地响应体。前者是常说的强缓存，后者是协商缓存。

先看状态：304 不是缓存没有命中

排查时先关闭“Disable cache”并区分正常加载、普通刷新和强制刷新。正常加载如果资源仍在新鲜期，Network 可能标成内存或磁盘缓存，甚至没有新的请求行；这才是直接复用。过期后，浏览器根据保存的校验器发起条件请求，响应为 304 时服务器确认版本没有变化，浏览器把旧响应体交给页面。若得到 200，说明资源版本变化或条件请求没有匹配，浏览器会接收新正文。

沿响应头判断是哪一层出了问题

Cache-Control: max-age=600 决定响应在一段时间内保持 fresh；没有明确策略时，浏览器可能采用启发式缓存，排查结果会因实现而不同。过期后重点看两组字段：响应里的 ETag 对应请求里的 If-None-Match，Last-Modified 对应 If-Modified-Since。通常 ETag 优先，匹配返回 304，不匹配返回 200。还要检查 Vary、Cookie 和查询参数，因为它们会改变缓存键或决定响应是否只能由单个用户使用。

HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable
ETag: "app-7c91"

// HTML 更需要及时确认，静态文件通过文件名版本化后再长缓存。
HTTP/1.1 200 OK
Cache-Control: no-cache, private
ETag: "html-20261008"

上面的两组策略不能互换：带哈希的构建产物换 URL 后，旧文件可以放心长缓存；入口 HTML 如果始终使用同一个 URL，使用 no-cache 配合 ETag 更容易拿到新版本。登录后的个性化响应还应考虑 private，避免被共享缓存错误复用。

用请求触发方式复现“看起来命中”的场景

刷新动作、开发者工具设置和脚本选项会改变缓存行为。Fetch 的 default 会优先读缓存，过期后再条件请求；no-cache 即使已有条目也会验证；no-store 不读也不写；force-cache 可以直接使用已有条目。它们是请求侧策略，不等价于服务器响应头。

async function loadConfig() {
  // no-cache 允许复用响应体，但要求服务器先确认是否变化。
  const response = await fetch('/config.json', { cache: 'no-cache' });
  if (!response.ok) {
    // 非 2xx 不应静默当成缓存命中，交给调用方处理错误。
    throw new Error(`配置请求失败：${response.status}`);
  }
  return response.json();
}

如果脚本在 URL 后追加随机参数，缓存键已经变化，浏览器自然会发起新请求；这不是“修复缓存”，而是主动绕开旧条目。排查时先记录 URL、请求头、响应头和触发方式，再改配置，避免把多个变量同时打开。

按资源类型落配置清单

最后重新执行一次正常加载和一次刷新：正常加载应尽量直接复用，过期或刷新后的验证应能在 304 与 200 之间给出可解释结果。不要只看“Size”列；真正有价值的是请求是否发出、条件头是否存在、响应状态是什么，以及正文是否重新传输。

常见问题

看到 304 是否说明服务器把文件重新传了一遍？

不是。304 通常只有响应头，浏览器把已有响应体与新的验证结果组合使用；但请求本身已经到达服务器。

no-cache 和 no-store 如何选择？

希望每次确认版本但仍节省正文流量时用 no-cache；不希望响应被存储时用 no-store，涉及隐私数据时还要结合 private 等策略。

为什么改了 JS 内容，用户仍拿到旧文件？

如果 URL 没变且仍在新鲜期，长缓存会继续复用旧版本。构建时给文件名加入内容哈希，并让 HTML 指向新 URL，通常比强制清空所有缓存更稳。