open_file_cache通过缓存文件元数据和句柄，跳过stat()和open()系统调用，避免磁盘查找；需同时配置max、inactive、valid、min_uses及errors四项参数，并配合系统限制与try_files优化才能生效。
open_file_cache 通过把文件元数据和句柄“记进内存”，让 Nginx 跳过反复调用内核的 open() 和 stat() 系统调用，从而直接避免磁盘查找。它不读文件内容，只缓存“这个路径是否存在”“是不是目录”“大小多少”“权限如何”这些判断结果——而这些正是每次请求都要查磁盘的关键动作。
缓存什么，跳过什么
每次请求静态资源时，Nginx 默认需执行以下内核操作：
- 调用
stat()查文件是否存在、是否为目录、mtime、权限等； - 若存在且可读，再调用
open()获取文件描述符（fd）； - 若路径是目录且启用了
index，还会额外尝试拼接/index.html并重复上述两步。
open_file_cache 把这些结果缓存在内存中。后续相同路径的请求，直接复用缓存值，完全绕过磁盘访问。
必须配齐的四项核心参数
单独写 open_file_cache on; 无效。以下四项需同时配置在 http 块中：
-
容量与淘汰：
open_file_cache max=10000 inactive=60s;—— 最多缓存 1 万个条目；60 秒内未被访问则标记为待清理 -
主动校验：
open_file_cache_valid 60s;—— 每 60 秒检查一次缓存项对应文件是否仍存在、是否被修改，防止返回过期状态 -
准入门槛：
open_file_cache_min_uses 2;—— 同一路径需在inactive时间窗内被访问至少 2 次才进入缓存，过滤偶然请求（如爬虫乱扫） -
错误也缓存：
open_file_cache_errors on;—— 把 “404 文件不存在”“403 权限拒绝” 等结果也记下来，避免同一非法路径反复触发磁盘查询
配合系统限制才能真正生效
光配 Nginx 不够，底层必须跟得上：
- 确认
worker_rlimit_nofile足够大（建议 ≥ 65535），否则缓存了 fd 也打不开 - 若启用
open_file_cache_events on;（依赖 inotify），需检查/proc/sys/fs/inotify/max_user_watches是否 ≥ 缓存条目数 × 1.5；否则 nginx -t 会报 “could not build optimal open_file_cache” - 避免在日志路径、上传目录、模板目录等非服务路径中意外触发缓存，防止缓存污染
搭配 try_files 减少隐式查找
当 index 和 try_files 同时存在时，Nginx 会先按 index 规则探测（触发多次 stat），再走 try_files fallback（可能再触发一次 open）。改用：
显式接管逻辑，让目录存在性判断也落入 open_file_cache 范围，进一步压缩磁盘查找次数。
