open_file_cache_min_uses的作用是设定文件进入长效缓存的访问频次阈值，需配合open_file_cache_valid构成观察窗口，仅高频访问文件才被缓存复用，从而提升热点文件句柄利用率。
open_file_cache_min_uses 的作用不是“提升句柄利用率”本身，而是精准识别并留住真正高频访问的静态文件，避免缓存被低频、偶然请求污染，从而让有限的缓存空间（max）始终服务于最热的文件——这才是提升热点利用率的关键逻辑。
它不控制句柄是否打开，也不影响请求能否响应，只决定：某个文件的元数据和句柄值，值不值得长期留在内存里复用。
理解 min_uses 的真实行为
- 它配合
open_file_cache_valid使用，定义一个“观察窗口”：比如valid 30s+min_uses 2，表示「该文件在最近 30 秒内被访问 ≥2 次，才允许进入长效缓存」 - 第 1 次访问：正常走系统调用（
stat/open），但不会驻留缓存 - 第 2 次（且在 valid 时间窗内）：Nginx 才把它纳入缓存，后续请求直接复用 fd 和元数据
- 未达阈值的文件仍能正常服务，只是每次都要查磁盘——这正是你希望避免的“冷路径”
按业务热度设置 min_uses 值
-
默认值
1不推荐：等于取消准入门槛，大量一次性图标、404 路径、调试文件会挤占缓存，降低整体命中率 -
min_uses 2是通用起点：适合大多数静态资源服务（如 SPA 的index.html、favicon.ico、核心 JS/CSS） -
min_uses 3–5更适合强热点场景：- 网关健康检查路径（如
/healthz）每秒多次请求，设为3可过滤瞬时抖动 - 构建产物中极少数关键资源（如
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的计时基准，也是元数据校验周期；设太短（<10s）徒增 CPU，太长（>120s）可能返回已删文件 -
open_file_cache_errors on;
→ 把高频 404（如缺失图片、误拼路径）也缓存住，否则min_uses对错误路径无效，照样反复触发磁盘查询
验证 min_uses 是否起效
没有日志直出，但可通过两个指标判断：
- 用
lsof -p $(pgrep nginx) | wc -l观察 worker 进程打开文件数：开启后应明显收敛（比如从 12000 降到 4000），说明热文件句柄复用成功 - 对比开启前后
perf stat -e syscalls:sys_enter_openat：若min_uses设置合理，openat系统调用次数应下降 40% 以上（尤其在小文件 QPS > 1k 场景）
注意：如果 min_uses 设得过高，而实际访问密度不够，你会看到缓存条目数偏低、openat 下降不明显——这时就要调低阈值或延长 valid。
