前端页面更新不及时主因是缓存链路拦截，需逐层排查：先查浏览器Network中index.html等资源状态（200 from cache/304说明缓存未更新），再验Nginx的$upstream_cache_status日志及curl -I响应头，区分静态文件缓存（HTML禁强缓存、JS/CSS用hash+immutable）与代理缓存（注意proxy_ignore_headers），最后确认Nginx、CDN及分布式存储缓存是否真正清理。
前端页面更新不及时，十有八九不是代码没部署，而是缓存链路上某一层“拦下了新内容”。排查要从浏览器→Nginx→后端（含分布式存储）逐层验证，不能只盯着配置文件看。
第一步：确认浏览器是否真的发出了新请求
打开浏览器开发者工具的 Network 面板，刷新页面，重点看关键资源（如 index.html、main.xxxx.js）的响应状态和响应头：
- 如果状态是 200 (from memory cache) 或 304 Not Modified，说明浏览器没发新请求，或发了但服务器说“没变”——问题在 HTML 或协商缓存逻辑
- 如果状态是 200 OK 但内容仍是旧的，说明请求已到达 Nginx，但 Nginx 返回的是缓存副本——问题在 Nginx 代理缓存或静态文件缓存
- 用 curl -I http://your-domain/index.html 对比响应头，排除浏览器插件或 DevTools “Disable cache” 开关的干扰
第二步：检查 Nginx 缓存行为是否真实生效
光看配置没用，得用日志和响应头“亲眼所见”：
- 在 Nginx 的 log_format 中加入 $upstream_cache_status，查看 access.log 中该字段值：HIT 表示命中缓存，MIS 表示未命中，EXPIRED 表示缓存过期后回源
- 对目标 URL 执行 curl -I，检查是否有 X-Proxy-Cache: HIT 或类似自定义缓存标识头；同时关注 Cache-Control、ETag、Last-Modified 是否符合预期
- 若使用了 proxy_cache，确认 proxy_cache_valid 是否覆盖了当前响应状态码（例如只配了 404 1m，但实际返回 200，则不缓存）
第三步：区分静态文件缓存 vs 代理缓存
这两类缓存机制完全不同，排查方向也不同：
立即学习“前端免费学习笔记（深入）”；
-
静态文件（直接由 Nginx serve）：检查 location 块中是否用了 expires 或 add_header Cache-Control。HTML 必须禁用强缓存（如
add_header Cache-Control "no-cache"），而带 hash 的 JS/CSS 应设为public, max-age=31536000, immutable - 代理缓存（proxy_pass 到后端）：检查是否误启用了 proxy_cache，且后端响应头含 Cache-Control: no-cache 或 private —— 默认情况下 Nginx 会跳过缓存。需加 proxy_ignore_headers Cache-Control 才能强制缓存
- 若静态资源挂载在 NFS/Ceph 等分布式存储上，还要验证挂载参数（如 NFS 的 actimeo=1）是否让文件 mtime 变更实时可见，否则 Nginx 的 if_modified_since 失效
第四步：验证缓存清理是否真正落地
改完配置 reload 不等于缓存就清了：
- 避免用 rm -rf /var/cache/nginx/* 后 reload，这会清空全部缓存，影响其他服务；推荐启用 ngx_cache_purge 模块，按 URL 精准清除：
curl -X PURGE http://domain/purge/assets/main.abcd12.js - 若用 CDN，别忘了它也有独立缓存层——Nginx 清了，CDN 还可能挂着旧内容。需同步调用 CDN 的刷新接口或设置较短的 TTL
- 发布后立即检查 HTML 文件本身是否更新：它才是“资源地图”，如果 HTML 还引用着旧 hash 名字的 JS，再清 JS 缓存也没用
