Open_file_cache会导致Nginx缓存文件元信息，若open_file_cache_valid设为0或min_uses过高，文件更新后无法及时感知；需检查配置是否启用、valid时间是否合理，并用strace验证stat调用。
Open_file_cache 会导致 Nginx 缓存文件的元信息（如存在性、权限、修改时间），若配置不当，静态文件更新后浏览器仍返回旧内容，实际是 Nginx 没有及时感知到文件变化。排查重点不是“是否缓存”，而是“缓存是否过期、是否校验、是否被绕过”。
确认 open_file_cache 是否启用并生效
检查 nginx.conf 中是否有类似配置：
open_file_cache max=1000 inactive=60s;<br>open_file_cache_valid 60s;<br>open_file_cache_min_uses 2;<br>open_file_cache_errors on;
关键点：
-
open_file_cache 必须显式开启（默认关闭），仅设
max和inactive才会启用缓存 - open_file_cache_valid 决定 Nginx 多久检查一次缓存项的文件状态（如 mtime）。若设为 0，Nginx 永远不重新校验，更新后必然延迟
- open_file_cache_min_uses 表示文件需被访问多少次才进入缓存。若设得过高（如 5），低频文件根本不会被缓存，也就不存在延迟问题
验证文件变更是否被 Nginx 检测到
用 strace 观察 Nginx worker 进程是否执行 stat() 或 open() 系统调用：
pid=$(pgrep -f "nginx: worker")<br>strace -p $pid -e trace=stat,open,openat -f 2>&1 | grep "your-file.js"
预期行为（当缓存项过期后）：
- Nginx 在
open_file_cache_valid间隔后，对缓存中的文件路径调用stat()获取最新 mtime - 若 mtime 变化，缓存项被标记为失效，下次请求会重新读取文件内容
- 若没看到
stat()调用，说明缓存项尚未过期，或该文件根本未进缓存（可能因min_uses未达标）
检查文件更新方式是否触发内核通知失效
常见陷阱：用 cp new.js old.js 或编辑器“保存覆盖”可能不改变 inode，只改内容 —— 但 Nginx 依赖的是 stat 返回的 mtime，只要 mtime 更新了就可检测。真正有问题的是：
- rsync --inplace：覆盖写入，mtime 可能不变（取决于源文件时间戳）
-
编辑器启用备份/原子写入（如 vim 的
backupcopy=no）：先删原文件再新建，inode 变更 → 原缓存项彻底失效，但新文件需重新满足min_uses才进缓存 - 容器或挂载卷中更新文件，宿主机时间不同步：导致 mtime 乱序，Nginx 认为“未更新”
建议更新时统一用 cp -p（保留时间戳）或 touch 强制更新 mtime。
临时绕过缓存快速验证
不改配置的前提下，快速判断是否为 open_file_cache 导致：
- 重启 Nginx：
nginx -s reload清空全部 open_file_cache，再请求看是否返回新内容 - 用
open_file_cache off;临时关闭缓存（需 reload），观察延迟是否消失 - 在 location 中加
open_file_cache off;针对特定路径禁用，缩小影响范围
注意：关闭后可能轻微增加系统调用开销，仅用于定位。
