问题根源是nginx的open_file_cache缓存文件元数据导致静态资源更新滞后，需检查配置、验证日志、调整或禁用该缓存，并注意sendfile和浏览器缓存干扰。
这个问题本质不是“缓存没刷新”，而是 Nginx 在开启 open_file_cache 后，对文件是否存在、是否变更的判断滞后了。它缓存的是文件元数据（如 inode、mtime、size），不是内容本身，但一旦缓存生效，Nginx 就不再实时 stat 文件，导致修改 HTML/CSS/JS 后仍返回旧版本。
确认是否启用了 open_file_cache
很多用户以为问题出在 proxy_cache 或浏览器缓存，其实根源常是静态文件层的 open_file_cache。检查 nginx.conf 中是否有类似配置：
open_file_cache max=1000 inactive=60s;open_file_cache_valid 60s;open_file_cache_min_uses 2;open_file_cache_errors on;
只要启用且 inactive 时间较长（比如设为 300s），就可能让 Nginx 在 5 分钟内都“看不见”你刚改过的文件。
验证元数据缓存是否生效
不用猜，直接看日志和响应行为：
- 临时加一条日志：在 server 或 location 块中加入
log_format debug '$request_filename $upstream_http_last_modified';，再配合access_log logs/debug.log debug; - 修改一个测试文件（如
test.html），用stat test.html查看 mtime 变化，再 curl 请求，对比日志里记录的$request_filename对应的最后修改时间是否同步 - 若日志中时间戳始终不变，说明
open_file_cache正在拦截真实文件状态
调整或禁用元数据缓存策略
开发环境或频繁更新静态资源时，不建议长期启用该缓存。可按需选择：
- 临时关闭：注释或删除
open_file_cache相关全部指令，执行nginx -s reload - 缩短失效周期：把
inactive改成10s，valid改成1s，例如：open_file_cache_valid 1s; open_file_cache_inactive 10s; - 排除关键目录：用
location精确控制，比如对开发目录禁用缓存：location /dev/ { open_file_cache off; }
别忘了清理浏览器和 sendfile 干扰
即使关掉 open_file_cache，页面还可能不更新，因为还有两层干扰：
-
sendfile：Windows 下默认开启，会绕过用户态校验，导致修改后仍发旧文件。解决方法是设
sendfile off;（Linux 下影响较小，但高一致性场景也建议关） -
浏览器强缓存：Nginx 若返回了
Cache-Control: max-age=31536000，浏览器根本不会重发请求。检查响应头，必要时加add_header Cache-Control "no-cache, must-revalidate";覆盖
改完记得清空浏览器缓存（Ctrl+Shift+R 或 DevTools → Network → Disable cache），否则所有服务端调整都白做。
