open_file_cache_valid控制nginx校验缓存文件元数据的周期，不决定条目存活时间；需按资源更新频率设为5–300秒，并与inactive、min_uses、errors协同配置，避免校验失效或开销过大。
open_file_cache_valid 并不控制“文件缓存有效期”，它控制的是 Nginx 对已缓存文件元数据的主动校验频率，即每隔多少秒执行一次 stat() 系统调用，检查缓存条目对应的真实文件是否仍存在、权限是否变化、inode 是否被替换等。它不决定缓存条目能“活多久”，那个由 inactive 决定；也不管理文件描述符（fd）本身在内核中的生命周期。
真正起作用的是：
-
inactive：定义缓存条目空闲多久后被自动淘汰（这才是“有效期”的实际体现）； -
valid：仅决定“多久查一次”——查完发现失效，才标记过期，下次访问才会重新打开。
怎么设 open_file_cache_valid 值才合理
根据静态资源的实际更新节奏来匹配，不是越小越好，也不是越大越省：
资源每 1–5 分钟发布一次（如 CI/CD 定时构建）
→ 设为30s：覆盖多数更新窗口，校验开销可控，响应延迟可接受支持秒级热更（如运营后台实时换图、灰度配置下发）
→ 可设10–20s，但需观察perf stat -e syscalls:sys_enter_statx中stat调用是否明显上升，避免系统调用压力过大资源基本不变（如哈希命名的 JS/CSS、CDN 分发的版本化产物）
→120s或300s都可以，大幅减少无效stat，提升 CPU 效率紧急调试或小流量灰度节点（非生产环境）
→ 可试5s，但上线前务必压测，防止 I/O 突增拖慢 worker
必须协同配置的参数
单独调 valid 没意义，以下参数必须配套设置：
open_file_cache max=10000 inactive=60s;
→inactive不能显著短于valid；例如valid 30s+inactive 10s，大部分条目根本活不到第一次校验，valid就形同虚设open_file_cache_min_uses 2;
→ 设为1会让所有首次访问都进缓存，大量临时路径或 A/B 测试资源会快速污染缓存，抬高校验负担open_file_cache_errors on;
→ 404/403 错误也会按valid时间缓存。若部署后持续约valid秒的 404，大概率是旧路径未清理干净或权限未同步
如何验证它真正在工作
查看系统调用频次：
perf stat -e syscalls:sys_enter_statx -p $(pgrep nginx)
开启前后对比，理想下降 40% 以上观察句柄数稳定性：
lsof -p $(pgrep nginx) | wc -l
开启后应趋于收敛，而非随请求量线性增长日志中加缓存状态标识（需自定义 log_format）：
log_format cache_log '$status $request_filename $upstream_http_x-cache';
配合$upstream_http_x-cache（需 upstream 设置响应头）辅助判断命中情况
不复杂但容易忽略
