验证nginx浏览器缓存表现的关键是观察真实请求行为：检查响应头是否按预期下发（如哈希资源用public/max-age=31536000，html用no-cache/must-revalidate），network面板中确认200→from disk cache→304的完整缓存链路，并通过更新哈希资源验证缓存切换逻辑是否正确。
验证生产环境中 Nginx 的浏览器缓存表现，关键不是“看配置有没有写对”，而是观察真实用户请求在浏览器端的实际行为——是否真的被缓存、何时失效、是否触发验证、有无误缓存。需从客户端视角出发，结合响应头、网络行为和资源变更场景交叉判断。
检查响应头是否按预期下发
打开浏览器开发者工具（F12）→ Network 标签页 → 刷新页面 → 点击任意静态资源（如 app.a1b2c3.js 或 logo.png）→ 查看 Response Headers：
- 带哈希的 JS/CSS/图片：应看到 Cache-Control: public, max-age=31536000, immutable
- HTML 文件：应看到 Cache-Control: no-cache, must-revalidate 或 private, max-age=0
- 通用静态资源（如未哈希的 favicon.ico）：应为 public, max-age=86400, must-revalidate
注意：不要只看 Expires；若同时存在 Cache-Control 和 Expires，以 Cache-Control 为准。若没看到对应头，说明 location 未匹配成功，或 add_header 被上级块覆盖（add_header 不继承，必须写在具体 location 内）。
观察实际加载行为与状态码
在 Network 面板中刷新多次，关注 Size 列和 Status 列的变化：
- 首次访问：资源显示 200 OK，Size 显示完整字节数（如 124 KB）
- 后续访问（未过期）：Size 显示 from disk cache 或 from memory cache，Status 仍为 200（强缓存生效）
- 缓存过期后访问：若服务端返回了 Last-Modified 或 ETag，浏览器会自动发带 If-Modified-Since 或 If-None-Match 的请求 → 服务端返回 304 Not Modified，Size 显示 0 B（协商缓存生效）
-
HTML 始终 200？正常——因为配置了
no-cache，每次都会发请求验证；但若返回 304，说明后端正确响应了条件请求，这是理想状态
模拟资源更新并验证缓存切换逻辑
部署一次带新哈希的 JS 文件（如 app.x7y8z9.js），同时保留旧文件，并观察行为：
- 旧 HTML 中仍引用
app.a1b2c3.js→ 浏览器继续使用本地强缓存（不发起请求） - 新 HTML 中改为引用
app.x7y8z9.js→ 浏览器识别为全新 URL，发起新请求并缓存，旧缓存不受影响 - 若误将 HTML 设为 long-term 缓存（如 max-age=1年），则用户可能长期卡在旧 HTML，无法加载新 JS —— 这是常见线上故障点
反向测试：临时修改一个未哈希的图片（如 /images/banner.jpg），刷新页面。若仍显示旧图，说明它被强缓存且未设 must-revalidate；若出现 304，则验证机制工作正常。
排查典型误缓存与失效场景
以下现象说明缓存策略存在风险，需立即检查：
-
HTML 返回 200 但内容未更新：可能是 CDN 或中间代理缓存了 HTML，而 Nginx 的
no-cache未穿透；可在响应头加 Vary: User-Agent 或强制设置Cache-Control: private -
JS/CSS 修改后用户仍加载旧版本：确认构建是否真正生成新哈希；检查 Nginx 是否因 location 正则太宽泛（如
location ~ \.js$）误匹配了 HTML 内联脚本，导致缓存头污染 -
DevTools 中显示 from disk cache，但 F5 刷新后内容异常：可能是 Service Worker 拦截并返回了错误缓存，需检查
navigator.serviceWorker是否注册
不复杂但容易忽略。
