Nginx 文件缓存：如何配置 open_file_cache_valid 定时校验本地静态文件缓存的有效性周期

open_file_cache_valid控制Nginx每隔指定秒数对缓存条目执行stat()校验文件存在性、权限及inode变化，不管理文件描述符生命周期；秒级热更设10–20秒，分钟级发布推荐30秒，稳定资源可设120秒以上，并须与inactive、min_uses、errors协同配置。

open_file_cache_valid 不是设置“缓存有效期”，而是控制 Nginx 每隔多久主动 stat() 一次已缓存的文件元数据——检查它是否还存在、权限有没有变、inode 是否被替换。校验结果决定缓存条目是否被标记为过期，但条目真正被清理，靠的是 inactive 时间。

按资源更新节奏设 valid 值

设得太短，系统调用暴增；设得太长，用户可能看到旧内容或 404：

• CI/CD 每 1–5 分钟发布一次（如前端打包部署）→ 设为 30s：覆盖多数更新窗口，开销可控
• 支持秒级热更（如运营后台实时换图）→ 可设 10–20s，但需监控 sys CPU 占比和 statx 系统调用频次
• 哈希命名的 JS/CSS、CDN 分发的版本化资源 → 120s 或 300s 即可，大幅减少无效校验
• 仅限灰度或小流量节点调试 → 可试 5s，上线前必须压测，避免 I/O 突增拖慢 worker

必须配套配置的参数

单独调 valid 没效果，以下四项需协同：

• open_file_cache max=10000 inactive=60s;：inactive 才是条目实际“存活时间”，应略大于 valid（例如 valid 30s + inactive 60s），否则很多条目活不到第一次校验就清掉了
• open_file_cache_min_uses 2;：防止带时间戳的调试 URL、A/B 测试路径等单次访问资源进缓存，抬高校验负担
• open_file_cache_errors on;：把 404、403 也缓存住，避免反复探测错误路径；但出错后会持续 valid 秒，需配合日志监控

验证与异常处理

校验是否生效，不能只看配置语法：

• 观察 lsof -p $(pgrep nginx) | wc -l：开启后打开文件数应趋于稳定并明显下降
• 查日志中 403/404 是否突增且持续约 valid 秒：大概率是部署漏了 chown 或路径写错，导致错误被缓存
• 紧急恢复时执行 nginx -s reload：立即清空整个 open_file_cache，比等自然过期快得多