open_file_cache_min_uses的作用是设定文件进入缓存的访问频次门槛，必须与inactive时间窗口配合使用，仅当同一文件在inactive指定时间内被访问≥设定次数时才允许入缓存，从而防止冷文件污染内存；默认值1不推荐，2最常用，需同步配置open_file_cache_valid和open_file_cache_errors才能完整生效。
open_file_cache_min_uses 的作用不是“筛选缓存”，而是控制哪些文件有资格进入缓存 —— 它设定了一个访问频次门槛，避免把偶然访问的一次性文件（比如 404 页面、临时上传路径、调试资源）塞进缓存，从而保护有限的内存空间和缓存命中率。
它怎么判断“够不够格”？
这个值必须和 inactive 时间配合生效。Nginx 不是看“总访问次数”，而是看：在 inactive 指定的时间窗口内，该文件是否被访问了至少 min_uses 次。
- 比如配置
inactive=30s min_uses=2：某 CSS 文件在 30 秒内被请求了 2 次，才正式加入缓存；如果只请求 1 次，哪怕后续再访问，只要中间间隔超过 30 秒，就重新计时 - 若设为
min_uses=1（默认值），等于取消门槛，所有被访问的文件都可能进缓存，容易被冷文件填满 - 设为
min_uses=3，则要求更“热”的访问模式，适合 CDN 回源或静态资源高度集中的场景
为什么不能只靠 max 或 inactive 来管理？
仅靠 max=2000 或 inactive=60s 无法区分“真热点”和“伪热点”。例如：
- 爬虫批量扫不存在的路径，触发大量 404 —— 若没开启
errors on+ 合理min_uses，这些错误会反复刷入缓存，浪费条目 - 用户上传临时头像，URL 带时间戳，每次都是新路径 —— 这类文件几乎不会重复访问，
min_uses=2能天然过滤掉 - 首页 JS 被大量用户并发加载，30 秒内轻松达到 10+ 次 —— 自然稳稳留在缓存中
搭配 errors 和 valid 才真正起效
min_uses 对错误响应也适用，但前提是 open_file_cache_errors on 已启用，且 open_file_cache_valid 设定合理：
- 错误（如 ENOENT）同样要满足 “在 inactive 时间内出现 ≥ min_uses 次”，才会被缓存
- 若
valid=60s，Nginx 每 60 秒检查一次这些错误是否仍存在；若文件后来被创建，缓存会自动更新 - 没有
valid，错误缓存就永远不会刷新，可能导致长期返回 404 即使文件已恢复
常见配置建议
根据实际流量特征调整，不追求绝对数值：
- 中小型站点（日均请求 ≤50 万）：
min_uses 2平衡灵敏与稳定 - 高并发静态服务（CDN 边缘节点）：
min_uses 3，配合inactive=10s，快速收敛热点 - 含大量动态路径或调试接口的开发环境：
min_uses 1可临时启用，但上线前务必调回 - 避免设为过高（如 5+），否则真实热点也可能因访问节奏分散而错过缓存
