浏览器强缓存未失效导致复用旧文件，需逐层排查：Network中看请求状态（304/200/无请求），检查Nginx路径配置、响应头（Cache-Control/Last-Modified/ETag）及sendfile机制。
静态资源改了，浏览器却还在用旧文件——这不是代码没生效，而是缓存链路上某个环节“卡住了”。排查要从客户端到服务端逐层验证，重点不是“有没有缓存”，而是“谁在缓存、缓存依据是什么、是否被跳过”。
看浏览器是否真的发出了新请求
打开开发者工具（F12），切换到 Network 标签页，刷新页面，找对应 CSS/JS 文件的请求：
- 状态码是 304：说明浏览器发了协商请求，但服务端返回“没变”，问题在 Nginx 或后端未正确响应变更（如 Last-Modified 或 ETag 未更新）
- 状态码是 200 但响应体内容仍是旧的：说明请求到达了 Nginx，但 Nginx 返回的是缓存副本或旧文件，需检查其文件读取路径和缓存配置
- 根本没出现该资源请求：大概率是浏览器强缓存生效（Cache-Control: max-age=31536000），它压根没发请求，Nginx 完全没参与
查 Nginx 是否读到了最新文件
确认你修改的文件确实存在于 Nginx 配置中指定的 root 或 alias 路径下，并且权限可读。常见陷阱：
- 用了 alias 但末尾多写了斜杠（如
alias /var/www/static/;），导致路径拼接错误，实际读取了旧目录 - 配置里写的是
root /var/www;，但文件放在/var/www/static/css/app.css，而请求 URL 是/css/app.css—— 这时 Nginx 实际查找的是/var/www/css/app.css，而非你认为的位置 - 启用了 sendfile on，且文件被内核缓存，修改后未触发 inode 变更或未等待足够时间，Nginx 内核零拷贝可能仍返回旧页缓存（尤其小文件）
验 Nginx 响应头是否误导了浏览器
用 curl -I http://your-domain/style.css 查看响应头，重点关注：
- Cache-Control 或 Expires：如果设了超长 max-age（如 1年），浏览器会直接复用本地副本，根本不问 Nginx
- Last-Modified：值是否随文件修改而更新？若 Nginx 用的是文件系统 mtime，而编辑器保存时未更新时间戳（如 vim 编辑后 :w! 强制覆盖），该头就不会变
-
ETag：默认由文件大小+mtime 生成，同样依赖文件元数据是否真实更新；也可用
etag off;关闭，改用更可控的方案
试绕过所有缓存快速定位
不依赖用户行为，用最小干预验证服务端真实输出：
- 临时在 location 块中加：
add_header Cache-Control "no-cache, no-store, must-revalidate";并重载 Nginx（nginx -s reload），再刷新——若此时显示新内容，说明原缓存头是根源 - 直接用
curl -H "Cache-Control: no-cache" http://localhost/style.css请求，对比响应体内容，确认 Nginx 本身能否读到新文件 - 在浏览器地址栏手动加版本参数，如
style.css?v=2，若生效，说明问题纯属 URL 未变导致缓存复用，应转向构建时哈希或版本化命名
真正卡住的往往不是某一个配置，而是浏览器强缓存 + Nginx sendfile + 未更新的 Last-Modified 三者叠加。一层层剥离，就能准确定位是前端该加哈希、Nginx 该调响应头，还是运维该清磁盘缓存。
