open_file_cache_valid 和 open_file_cache_min_uses 必须协同工作：前者设定缓存条目元数据校验周期（如30s），后者定义文件在inactive窗口内需成功访问的最低次数（如2次）才准入缓存。
open_file_cache_valid 和 open_file_cache_min_uses 是 Nginx 静态资源 IO 优化中必须协同工作的两个关键参数，单独设置任一者都无效。它们不控制缓存是否开启，而是共同定义“缓存什么”和“何时确认它还有效”。
open_file_cache_valid：决定变更感知的最大延迟
它设定 Nginx 主动检查缓存条目元数据（是否存在、权限、修改时间）的周期，单位为秒。这不是实时监听，而是轮询校验。
- 设为
30s，表示最多 30 秒内无法感知文件被删除或重命名；设为120s，则最坏延迟达 2 分钟 - 值太小会增加
stat()系统调用压力；太大则导致过期响应（如文件已恢复但仍在返回 404） - 必须满足
inactive ≥ valid，否则多数条目在校验前就被淘汰，valid 实际失效 - 开启
open_file_cache_errors on后，404/403 错误也会被缓存 valid 秒，部署出错时用户看到的错误不会立刻消失
open_file_cache_min_uses：决定哪些文件有资格进缓存
它不是“访问次数越多越容易缓存”，而是一道准入门槛——只有在 inactive 时间窗口内被成功访问 ≥ 指定次数的文件，才允许写入长效缓存。
- 例如
inactive=60s; min_uses=2：某 JS 文件在 60 秒内被请求 2 次，第 2 次才正式入缓存；第 1 次仍走磁盘 - 默认值
1等于取消筛选，易被爬虫路径、调试资源、带时间戳的临时文件填满缓存 - 通用场景推荐
2；高频健康检查接口可设3–4；构建产物中极少数核心文件（如 runtime.js）可设4 - 该参数对错误响应也生效，但前提是
open_file_cache_errors on已启用
二者如何配合工作
它们共同构成一个“观察-准入-验证”闭环：
-
min_uses在inactive窗口内统计访问频次，决定“能否进” -
valid每隔固定时间重新stat缓存中的条目，决定“还能不能留” - 未达
min_uses的文件，即使被打开过，也不会进入长效缓存，每次请求都走冷路径（触发磁盘 stat/open） - 已入缓存的文件，若在下次
valid校验时发现已被删或权限变更，会立即标记失效并清理
典型配置与验证要点
推荐组合示例：
open_file_cache max=8000 inactive=60s;open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
验证是否起效，不能只看配置加载成功，需观察运行态：
- 用
strace -e trace=open,stat -p $(pgrep nginx)跟踪同一静态文件的多次请求，确认第二次起是否跳过系统调用 - 对比开启前后
iostat -x 1中的r/s（每秒读请求数），热资源服务阶段应明显下降 - 若某文件始终未被缓存，先排查是否在
inactive窗口内达到了min_uses次成功访问（排除 404、权限错误干扰）
