open_file_cache_min_uses 是筛选高频访问文件进入长效缓存的阈值参数，需与 open_file_cache_valid 配合使用：例如设为 2 和 30s 时，文件须在 30 秒内被访问 ≥2 次才写入缓存，首次访问仍走磁盘，未达标者持续触发冷路径；默认值 1 易致缓存污染，推荐通用值为 2，热点资源可设 3–5，但须协同 open_file_cache、open_file_cache_valid、open_file_cache_errors、open_file_cache_events 四项配置生效，并通过缓存命中率和磁盘 i/o 变化验证效果。
open_file_cache_min_uses 不是“让文件进缓存”的开关，而是决定“哪个文件值得长期留在缓存里”的筛选器。它和 open_file_cache_valid 搭配使用，共同构成一个观察窗口，只把真正高频访问的静态文件元数据（fd、mtime、size、存在性等）保留在内存中，避免缓存被一次性请求、404路径或调试资源挤占。
它怎么判断一个文件够不够“热”？
必须结合 open_file_cache_valid 才有意义：
- 比如设为
open_file_cache_valid 30s; open_file_cache_min_uses 2;，意思是：一个文件在最近 30 秒内被访问 ≥2 次，Nginx 才把它纳入长效缓存 - 第 1 次访问：走正常系统调用（
stat/open），不进缓存 - 第 2 次（且在 30 秒内）：才把 fd 和元数据写入缓存，后续请求直接复用
- 没达阈值的文件仍能响应，只是每次都要查磁盘——这就是你希望减少的“冷路径”
不同业务场景下的推荐取值
默认值 1 实际上等于取消门槛，容易导致缓存污染：
-
min_uses 2是通用起点：适合 index.html、核心 JS/CSS、favicon.ico 等用户二次加载概率高的资源 -
min_uses 3–5适合强热点路径：如健康检查接口/healthz（每秒多次）、构建产物中全局共用的runtime.js - 容器或低内存环境慎用过高值：若
valid时间短（如 20s），min_uses 5可能让真实热点也难达标，反而降低复用率
必须配套生效的其他参数
单独调 min_uses 没效果，它依赖以下四项协同工作：
-
open_file_cache max=8000 inactive=60s;：设定缓存容量上限；inactive要略长于valid，保证冷条目有足够时间被淘汰 -
open_file_cache_valid 30s;：既是min_uses的计时基准，也是元数据校验周期；太短（120s）可能返回已删文件 -
open_file_cache_errors on;：把高频 404 或权限错误也缓存住，否则缺失图片、误拼路径会反复触发磁盘查询，min_uses对它们完全无效 -
open_file_cache_events on;（推荐）：启用 inotify 实时监听文件变更，比轮询更及时；若不支持可关，靠valid轮询兜底
验证它是否起作用
Nginx 没有直接日志输出 min_uses 行为，但可通过两个指标间接判断：
- 缓存命中率提升：用
nginx -V确认模块已启用后，观察open_file_cache_hits/open_file_cache_misses比值是否上升 - 磁盘 I/O 下降：监控
sysstat中的%util和await，尤其在静态资源集中访问时段，open/stat 系统调用应明显减少
