open_file_cache_min_uses 是文件进入缓存的准入门槛，非清理阈值；它要求文件在 inactive 时间窗口内被访问≥指定次数才可入缓存，配合 inactive、valid 和 errors on 共同优化缓存效率与资源占用。
open_file_cache_min_uses 不是“清理阈值”，而是“准入门槛”——它决定一个文件是否值得被缓存，而不是决定已缓存的条目何时被删。
它管的是“进”，不是“出”
缓存条目的释放由 inactive 和 valid 控制：
- inactive=60s 表示某文件在 60 秒内没被访问，就标记为可淘汰；
- valid=60s 表示每 60 秒检查一次缓存项是否仍有效（如文件是否被删除）。
而 min_uses 在这之前就起作用：只有在 inactive 时间窗口内被访问 ≥ 指定次数，该文件才允许进入缓存。
- 设为
1：所有访问过的文件都进缓存 → 冷门路径（如临时调试页、爬虫乱扫）也占位 → 容易引发“进—闲置—淘汰—再进”的句柄抖动 - 设为
2或更高：单次访问直接被过滤，只留下有复用可能的文件（如 favicon.ico、common.css）→ 缓存更“干净”，fd 波动明显减少
常见取值与适用场景
数值选择应匹配业务访问模式，而非盲目调高：
-
常规静态服务（官网、文档站）：推荐
min_uses 2—— 平衡命中率与缓存纯净度 -
CDN 边缘节点或构建产物部署：可设
3—— 文件极少变更，只缓高频稳定资源 -
灰度发布频繁的前端项目：建议
4—— 新旧版本文件交替多，避免刚上线就被缓存又快速失效 -
内存受限环境（如小容器、边缘设备）：宁可设
3甚至5，也不让冷文件挤占空间
搭配 inactive 才真正生效
min_uses 的时间窗口就是 inactive 值。例如：inactive=30s; min_uses=3，意味着同一文件需在 30 秒内被访问满 3 次，才进入缓存。
- 若
inactive设得太短（如 10s），即使设min_uses=3，用户也很难在 10 秒内点三次同一个 JS 文件 → 实际效果接近min_uses=1 - 若业务存在周期性批量请求（如每 2 分钟拉一次配置），
inactive可设为120s或300s，给复用留出合理时间窗
别忘了 errors on 这个搭档
开启 open_file_cache_errors on 后，404、403 等错误也会被缓存——但前提是这些错误也要满足 min_uses 条件。否则，反复 404 的路径仍会不断触发 stat 调用。
- 搭配
min_uses 2：偶发 404 不缓存；连续两次 404 才缓存错误，避免无效探测刷爆 stat - 注意：
valid必须启用，否则错误缓存永不过期，可能导致误判
