Nginx 中如何配置静态资源的缓存检查频率

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，比等自然过期快得多

不复杂但容易忽略