open_file_cache_valid 控制 nginx 对缓存文件元数据的 stat() 校验周期，非内容刷新或浏览器缓存控制；需配合 inactive、min_uses、errors 使用，值应依更新频率设定：ci/cd 频繁发布设 30 秒，秒级热更可设 10–20 秒，哈希命名资源可设 120–300 秒。
Nginx 中静态资源的“缓存检查频率”实际指的是 open_file_cache_valid 指令控制的元数据校验周期——它决定 Nginx 每隔多久对已缓存的文件状态（是否存在、权限、inode 是否变化）执行一次 stat() 系统调用，而非刷新内容或控制浏览器缓存。
这个值不等于“缓存有效期”，而是校验节奏。设得太短会增加系统调用压力；太长则可能让 404 或旧文件残留更久。
按更新节奏选值
CI/CD 频繁发布（如每 1–5 分钟部署前端）→ 设为 30 秒
覆盖多数更新窗口，平衡及时性与开销支持秒级热更（如运营后台实时换图）→ 可设 10–20 秒
需配合监控sysCPU和statx调用频次，避免 I/O 过载哈希命名资源（如
app.a1b2c3.js）、CDN 分发的版本化文件 → 120 秒或 300 秒
文件名变即新资源，旧缓存条目极少变更，大幅减少无效校验灰度或小流量节点调试 → 可试 5 秒
上线前必须压测，防止 worker 被频繁stat拖慢
必须协同配置的参数
仅调 valid 没效果，需和以下三项配合：
open_file_cache max=10000 inactive=60s;inactive是条目真实存活上限，应明显大于valid（例如valid 30s + inactive 60s），否则很多条目还没等到第一次校验就被清掉了open_file_cache_min_uses 2;
防止单次访问路径（如带时间戳的调试 URL）进缓存，抬高校验负担open_file_cache_errors on;
把 404、403 错误也缓存住，避免反复探测错误路径；但出错后会持续缓存约valid秒，需结合日志监控
验证是否生效
- 看
lsof -p $(pgrep nginx) | wc -l：开启后打开文件数应趋于稳定并明显下降 - 查 access/error 日志中 403/404 是否突增且持续约
valid秒：大概率是部署漏了或路径写错，导致错误被缓存 - 紧急时可用
nginx -s reload清空整个open_file_cache，比等自然过期快得多
不复杂但容易忽略
