open_file_cache_min_uses 是文件缓存准入门槛，仅在 inactive 时间窗内成功访问 ≥ 次数才缓存元信息和 fd；需配合 max、inactive、valid、errors on 等参数协同生效。
open_file_cache_min_uses 的作用不是“节省内存”，而是让有限的缓存空间只留给真正值得缓存的文件——它是一道准入门槛，不是清理开关。设对了，冷数据进不来，热数据留得稳，内存自然用得高效。
它怎么过滤低频文件
这个参数只在文件首次被访问时启动计数，且仅统计成功返回 200 的请求。它和 inactive 搭配使用：
- 在
inactive定义的时间窗口内（比如 60 秒），同一路径被成功访问 ≥min_uses次，才允许该文件的元信息和 fd 进入缓存 - 计数不跨窗口，也不累计；没达次数的请求，根本不会生成缓存条目，自然不占内存
比如：
-
min_uses=1→ 所有首次访问都进缓存，爬虫扫的、探针单次调的、用户输错的路径全塞进来 -
min_uses=2→ 至少刷新一次页面或二次加载才能进缓存，天然过滤掉大量一次性请求 -
min_uses=3→ 适合明确有节奏复访的资源（如监控 SDK 每 10 秒拉一次，配合inactive=30s）
合理取值要匹配实际访问节奏
不同资源类型，复访频率差异大，不能一刀切：
- 普通 HTML/JS/CSS/图标：
min_uses=2+inactive=60s最稳妥，覆盖用户回刷、跳转再返回等常见行为 - 健康检查路径（如
/health）：min_uses=2～3+inactive=20s～30s，贴合探测间隔，避免把临时路径当热资源 - 首屏核心 JS 或字体：
min_uses=3+inactive=60s，提升驻留稳定性，减少反复 open/stat - 大量小图标或 fallback 字体：
min_uses=3～4+inactive=60s，防止低频图标挤占关键资源位置
必须配合其他参数才真正起效
单独设 min_uses 没意义，它只是筛选器，后面还得靠整套机制兜底：
-
max=N：定总量上限，比如max=10000约占 5～10MB 内存，按站点静态资源量预估（5k 图片 + 2k 脚本 ≈ 8k 条目） -
inactive=T：决定窗口长度，太短（如 10s）会让首屏资源刚缓存就淘汰；太长（如 300s）会导致已下线文件残留，404 响应延迟更新 -
valid=T：每 T 秒主动 stat 一次缓存项，校验文件是否还存在、权限是否变更，建议设为inactive的 0.5～0.8 倍（如inactive=60s→valid=30s） -
errors on：把 404、403 等错误结果也缓存住，否则无效路径会反复触发系统调用，隐性耗 CPU 和 inode 查询
实际验证方法
改完配置后别只看数字，用真实行为验证是否生效：
- 用
strace -p $(pgrep nginx) -e trace=open,stat观察：第二次请求同个 JS 文件时，open()和stat()系统调用是否明显减少 - 注意路径区分：
/a.js?v=1和/a.js?v=2是两个不同条目，各自独立计数 - 如果某 CSS 没进缓存，先确认它是否真在
inactive时间窗内被连续成功访问了 ≥min_uses次
不复杂但容易忽略
