open_file_cache_min_uses 是访问频次驱动的缓存晋升阈值，文件需在 open_file_cache_valid 周期内被重新打开≥指定次数才标记为活跃；须与 open_file_cache 和 open_file_cache_valid 配合使用，过小导致缓存膨胀，过大降低命中率。
open_file_cache_min_uses 不直接“筛选”文件，而是决定一个文件是否值得被保留在 open_file_cache 中——它基于该文件在缓存有效期内被重复访问的次数阈值来触发“晋级保留”。
作用机制：访问频次驱动的缓存晋升
启用 open_file_cache 后，Nginx 会缓存文件的描述符、元数据（如是否存在、是否为目录、权限、mtime 等）。但新打开的文件默认处于“临时观察状态”，只有当它在 open_file_cache_valid 指定的时间窗口内，被实际请求达到或超过 open_file_cache_min_uses 次，才会被标记为“活跃”，进而更可能长期驻留缓存（直到被 LRU 清理或超时）。
换句话说：它不是白名单式筛选，而是通过使用热度“投票”决定哪些文件值得缓存更久。
典型配置组合与行为逻辑
该指令必须配合 open_file_cache 和 open_file_cache_valid 使用才生效。常见搭配如下：
-
open_file_cache max=1000 inactive=60s;—— 最多缓存 1000 个条目，60 秒未被访问则标记为非活跃 -
open_file_cache_valid 60s;—— 每 60 秒检查一次缓存项有效性（比如文件是否被删除/修改） -
open_file_cache_min_uses 2;—— 在上一个valid周期内，若某文件被请求 ≥2 次，则下次检查时更大概率保留在缓存中
注意：min_uses 是统计“命中缓存后仍需 open() 的次数”（即缓存未命中后重新打开），而非所有 HTTP 请求次数。例如：静态资源首次请求触发 open → 记 1 次；第二次请求若缓存未过期且文件未变，则直接复用 fd，不计入计数。
如何影响真实缓存内容？
设置值过小（如 1）会让大量低频文件快速进入缓存，加剧内存占用和 LRU 压力；设得过大（如 10）则高频资源也可能因单次 burst 访问未达阈值而反复打开，失去缓存收益。
建议根据业务特征调整：
- 静态资源（CSS/JS/图片）稳定且复用高 → 可设为
2或3 - 动态生成文件或更新频繁的资源 → 即使设为
1效果也有限，应优先考虑禁用缓存或缩短inactive - 日志或监控接口等极少复用路径 → 不应依赖此机制，可配合
open_file_cache off或 location 级关闭
验证是否生效的方法
无法直接列出“当前哪些文件满足 min_uses”，但可通过间接方式观察效果：
- 开启
open_file_cache_errors on;，配合 error_log notice，查看是否有大量 “open() failed” 日志 → 表明缓存未命中率高，可能 min_uses 设置偏高或 valid 时间太短 - 用
strace -p $(pidof nginx) -e trace=openat,close抓取 worker 进程系统调用，对比开启/关闭 cache 后 openat 调用频次变化 - 监控
nginx_http_open_file_cache_hits/nginx_http_open_file_cache_misses（需 Prometheus + nginx-exporter）→ hit ratio 持续低于 70% 时，可尝试调低 min_uses
