open_file_cache_min_uses的核心目的是过滤低频文件，仅缓存被反复访问的热资源；它需与open_file_cache等配合使用，设定文件在inactive窗口内至少成功访问次数才可入缓存，典型值为2。
配置 open_file_cache_min_uses 的核心目的，就是让 Nginx 只缓存那些真正被反复访问的文件，避免把偶然请求、探测路径或低频资源塞进缓存，浪费内存还拉低命中率。它不单独起作用，必须和 open_file_cache、open_file_cache_valid、open_file_cache_errors 一起配置才生效。
min_uses 是怎么工作的
这个参数设定了一个“访问门槛”：同一个文件，在 inactive 时间窗口内，至少被成功请求多少次，才会被允许进入缓存。比如设为 2，意味着该文件在 60 秒（假设 inactive=60s）内被访问第 2 次时，Nginx 才会把它加入缓存；第 1 次访问仍走完整磁盘查询流程。
- 值为
1：所有被访问的文件都可能进缓存，容易混入冷数据，不推荐 - 值为
2：最常用、最稳妥的选择，能过滤掉大部分单次探测和误访 - 值为
3或更高：适合静态资源极多但真正热的文件极少的场景（如大型 SPA 中仅少数 JS/CSS 被高频加载），可进一步收紧准入
结合 inactive 设置才有效
min_uses 的计数周期完全依赖 inactive 参数定义的时间窗口。如果 inactive 太短（比如 10s），即使用户连续刷新页面，也可能跨窗口导致计数重置；如果太长（比如 300s），冷热切换变慢，缓存响应滞后。
- 对健康检查或网关探针类路径（如
/health）：建议inactive=20s～30s+min_uses=2，匹配探测频率 - 对 React/Vue 构建产物（index.html、main.js、logo.png）：可用
inactive=20s+min_uses=2，加快热资源入缓存 - 对图标/字体等大量小资源（如
/fonts/*.woff2）：可延长至inactive=60s+min_uses=3，确保稳定复用
注意它只统计“成功访问”
min_uses 不统计 404、403 等错误请求——这些由 open_file_cache_errors on 单独控制是否缓存。也就是说，一个路径反复返回 404，只要开了 errors on，它也会被缓存，但不会触发 min_uses 计数。所以高频 404 不会影响正常资源的缓存准入逻辑。
- 若发现某些本该热的文件没进缓存，先确认它们是否真在
inactive窗口内被访问了足够次数 - 可通过
nginx -t验证语法，再用curl多次请求目标文件，配合strace -p $(pgrep nginx) -e trace=open,stat观察系统调用是否减少来验证效果
典型配置示例
以下放在 http 或 server 块中即可：
open_file_cache max=5000 inactive=30s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
这套组合让 Nginx 对每秒数十次访问的 index.html 或探针文件快速建立缓存，同时自动忽略单次扫描类请求，句柄复用效率明显提升。
