open_file_cache_min_uses的核心作用是作为热度筛选门，仅允许在inactive指定时间窗口内访问次数≥设定值的文件进入缓存，从而防止低频、临时路径污染缓存空间。
open_file_cache_min_uses 的核心作用，就是给缓存加一道“热度筛选门”——它不阻止 Nginx 处理请求，而是让冷门文件根本进不了缓存，从而从源头防止内存被低频、临时或试探性路径占满。
它怎么拦住冷文件
这个参数必须和 open_file_cache inactive=… 配合使用。Nginx 会为每个文件路径单独计数：在 inactive 规定的时间窗口内（比如 60 秒），该路径被成功访问了多少次。只有达到或超过 min_uses 设定的次数，才允许把它的句柄和元数据存进缓存。
- 设为 1：所有被访问的文件都可能进缓存，包括爬虫扫出的 404、调试时随手敲的 /test.js、CI 构建预览的一次性 URL —— 这些全是冷数据，但全被收进去了
- 设为 2：首次访问仍走完整磁盘查询（stat + open），只有同一路径在窗口内再被访问一次，才正式入缓存。这就自然过滤掉单次探测、误输路径、首屏加载后不再复访的资源
- 设为 3 或更高：适合资源极多、内存紧张的场景，比如前端有上万份带 hash 的 JS 文件，但真正被用户反复加载的可能只有 main.js 和 vendor.js 几个
哪些冷文件最常被误收
以下几类路径若不设门槛，极易成为缓存“垃圾”：
- 带随机参数的请求，如
/log?t=1746216840123&r=abc或/api/track?uid=123&v=4.2.1—— 每次都是新路径，但都不值得缓存 - 上传后的临时预览地址，如
/upload/temp_abc123.jpg，前端加载一次就废弃 - 健康检查之外的探测路径，如
/healthz/debug、/ping?test=1，只在部署时触发一两次 - 错误路径本身，比如大量
/favicon.ico、/robots.txt不存在时反复被请求 —— 若开了 open_file_cache_errors on，它们也会被缓存“404”，但前提是满足 min_uses
配合 inactive 调整才精准
min_uses 的效果高度依赖 inactive 时间长度。窗口太短，真实热资源可能跨窗计数归零；窗口太长，冷文件滞留时间过久。
- SPA 首页（如 /index.html）每秒被刷几次 → inactive=20s + min_uses=2 更快命中
- 字体/图标等小文件集中加载，但后续无复访 → inactive=60s + min_uses=2 可平衡覆盖与淘汰
- 网关探针路径（如 /health）每 5 秒一次 → inactive=15s + min_uses=2 确保稳定进入缓存
- 日志中高频出现但仅访问 1 次的路径 → 即使 inactive=300s，min_uses=2 也能让它永远进不去
验证是否真起效
不用复杂监控，两个简单方法可判断：
- 用
lsof -p $(pgrep nginx) | wc -l查看 worker 进程打开的文件数。开启合理 min_uses 后，该数值应明显低于 max 设置值，且趋于稳定（说明冷路径没挤占条目） - 对一个冷路径（如 /test-xyz.css）连续 curl 一次，隔 61 秒再 curl 一次 → 它不会进缓存；而连续两次在 60 秒内请求，才会看到第二次系统调用减少（可用
strace -p $(pgrep nginx) -e trace=open,stat观察）
