open_file_cache_min_uses 是访问频次门槛，仅当文件在 inactive 时间窗口内被访问≥指定次数时才缓存其句柄和元数据；默认值1不推荐，2最常用，需与 inactive 配合使用。
open_file_cache_min_uses 的作用不是“确保缓存”，而是设一个访问频次门槛——只有满足这个门槛的文件，才会被放进 open_file_cache。它本身不决定是否启用缓存，而是配合 inactive 时间窗口一起过滤掉偶然访问、低频请求，避免缓存被冷数据占满。
它怎么工作？
该参数必须和 open_file_cache inactive=...s 搭配使用。Nginx 会统计：在 inactive 设定的时间段内（比如 60 秒），同一个文件路径被请求了多少次。只有达到或超过 min_uses 指定的次数，这个文件的元数据和句柄才会被正式加入缓存。
例如：
open_file_cache max=5000 inactive=60s;<br> open_file_cache_min_uses 2;
意味着：某文件在任意连续 60 秒内被访问 ≥2 次，才可能进缓存；如果只访问 1 次，哪怕之后立刻再访问一次但已跨过 60 秒窗口，也不算。
设成多少合适？
- 默认值 1 不推荐：等于取消门槛，所有文件只要被访问就进缓存，容易让临时探测、爬虫试探、错误路径等低价值条目挤占空间
-
2 是最常用且稳妥的取值：能有效过滤单次请求（如首次加载、调试探查），又不会错过真实高频路径（如
/index.html、/healthz、/favicon.ico） -
设为 3 或更高：适合资源极多、内存紧张，或明确知道某些文件访问节奏更密的场景（如前端监控 SDK 的上报文件每 10 秒固定拉一次，可配
inactive=30s; min_uses=3）
注意几个关键点
- 它只对“同一路径”计数，不区分 query 参数（
/a.js?v=1和/a.js?v=2视为不同路径） - 它不缓存内容，只影响“是否缓存该文件的句柄和元数据”，所以不会改变响应体或状态码
- 即使未达
min_uses，Nginx 仍会执行stat()和open()，只是不把结果存进缓存 - 若同时开了
open_file_cache_errors on，404/403 等错误也参与计数——即某个不存在路径被连续请求 2 次，也会被缓存“不存在”结果
搭配 inactive 调整更精准
min_uses 的效果高度依赖 inactive 的长度。比如：
- 健康检查路径
/healthz每 5 秒调一次 → 可设inactive=15s; min_uses=2，确保稳定命中 - 用户上传头像后前端立即预览 → 访问间隔可能几秒，但后续无复访 → 这类不适合进缓存，靠
min_uses=2自动过滤 - 构建产物目录下大量 JS/CSS 文件，首屏加载时集中触发 → 若
inactive太短（如 10s），可能部分文件刚进缓存就被淘汰；建议inactive=60s配合min_uses=2
