open_file_cache_min_uses需与inactive联动，作为时间窗口内访问频次过滤器：仅在inactive指定时段内达min_uses次数的文件才入缓存；须配合max、valid、errors参数协同生效，并依资源类型分层设阈值。
要让 open_file_cache_min_uses 真正起到“只留热点、不养冷数据”的作用，关键不是盲目提高数值，而是把它当作一个时间窗口内的访问频次过滤器——只有在 inactive 定义的时间段里被反复请求的文件，才配拥有常驻内存的资格。
它不是计总数，而是在窗口里数“够不够热”
这个参数必须和 open_file_cache inactive= 联动生效。Nginx 不统计“一生访问多少次”，而是盯住“最近 N 秒内是否至少被访问了 M 次”：
- 比如设为
inactive=60s; min_uses=2：某 JS 文件在任意连续 60 秒内被请求第 2 次时，才正式进缓存；第 1 次仍走磁盘查询 - 若设为
inactive=20s; min_uses=3：意味着该文件得在 20 秒内被密集访问 3 次（如每 6 秒一次），才能过关 - 跨窗口即重置——前 59 秒访问 1 次，第 60 秒再访 1 次，不算达标；必须落在同一个时间窗内
按资源类型分层设阈值，避免一刀切
不同路径的访问节奏差异很大，统一设 2 或 5 都容易失衡：
-
核心入口类（如
/index.html、/healthz）：设min_uses=2即可。它们本就高频稳定，门槛太低会混入调试路径，太高反而卡住首屏加速 -
构建产物中的关键资源（如
/js/runtime.js、/css/app.css）：配合inactive=60s，设min_uses=2～3更稳妥。首屏加载集中触发，能稳稳捕获 -
图标/字体等海量小资源（如
/fonts/*.woff2）：可延长inactive=120s并设min_uses=3，确保真正被复用的才留下，避免缓存被一次性加载塞满 -
探测或临时路径（如带时间戳的
/debug?ts=123）：天然无法达标，min_uses=2就能自动过滤，不用额外排除
必须同步配齐的配套参数
min_uses 单独存在等于没开。它依赖以下三项共同构成闭环逻辑：
-
open_file_cache max=10000 inactive=60s;：划出缓存容量和冷淘汰节奏，inactive必须与min_uses的窗口对齐 -
open_file_cache_valid 30s;：决定元数据多久校验一次。设为inactive的一半左右较合理（如 inactive=60s → valid=30s），既保新鲜又不过载 -
open_file_cache_errors on;：把高频 404 也缓存住，否则错误路径反复刷访问却不算min_uses计数，会干扰真实资源的准入判断
验证它是否真在筛选热点
没有日志直出，但可通过两个可观测指标确认效果：
- 用
lsof -p $(pgrep nginx) | wc -l查看 worker 进程打开的文件数：开启合理配置后，该数值应明显下降并趋于稳定（说明句柄复用成功，冷路径不再反复 open） - 用
strace -p $(pgrep nginx) -e trace=open,stat抓几秒系统调用：高频路径的open/stat调用应大幅减少，而低频路径仍保持原样——这正是你想要的“区别对待”
