直接配置 open_file_cache 能减少重复打开文件次数，它不缓存文件内容，只缓存文件描述符、存在性、权限、修改时间等元信息，需同时配置 max、inactive、valid、min_uses 和 errors 五项参数才生效。
直接配置 open_file_cache 就能减少重复打开文件次数——它不缓存文件内容，而是把“文件是否存在”“能否读取”“修改时间是多少”这些元信息，连同已打开的文件描述符（fd）一起记在内存里。后续相同路径的请求，Nginx 直接复用缓存结果和 fd，跳过 open() 和 stat() 系统调用，自然就避免了反复打开。
必须配齐的四个核心参数
只写 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;——同一文件至少被连续请求 2 次才进缓存，防冷路径污染
- open_file_cache_errors on;——把 “文件不存在”“没权限” 这类错误也缓存住，避免反复探测无效路径
让缓存真正复用 fd 的关键条件
缓存 fd 的前提是 Nginx 能稳定持有句柄，需配合底层限制与行为控制：
- 确保
worker_rlimit_nofile足够大（建议 ≥ 65535），否则缓存再多 fd 也打不开 - 若启用
open_file_cache_events on;（依赖 inotify），需调高/proc/sys/fs/inotify/max_user_watches，否则会报 “could not build optimal open_file_cache” - 静态资源 location 尽量用前缀匹配（如
location /static/），避免正则匹配导致路径解析开销干扰缓存命中 - 搭配
sendfile on;使用，让内核直接传输内容，不再经过用户态读写，进一步减少 fd 使用压力
按业务特点微调参数更稳妥
默认值适合日均几万到百万级请求的静态服务，但实际要根据文件更新频率和资源规模调整：
- 构建后部署的 Vue/React 产物（极少变动）：可设
inactive=300s、valid=120s，降低校验频次 - CDN 或大型 SPA（文件种类多、内存充足）：
max可提到 20000～50000，注意每个条目约占 1KB 内存 - 容器环境或小规格云实例（IO 弱、内存紧）：保持
min_uses 2，避免缓存抖动；max不宜盲目拉高 - 后端有外部进程频繁更新文件（如动态路由 JSON）：
valid宜设为 30s 左右，防止读到过期元数据
验证是否真的减少了 open 次数
不能只看配置加载成功，得观察真实系统行为：
- 对比开启前后：
lsof -p $(pgrep nginx) | grep REG | wc -l查看 worker 进程打开的普通文件数是否明显下降并趋于稳定 - 压测时监控
sysstat中的%sys（系统调用开销）是否降低、%util（磁盘利用率）是否更平稳 - 如有调试版 Nginx，可开启
open_file_cache_log on;，从error_log中查看 hit/miss 统计
