直接启用 open_file_cache 是最有效方式——它缓存文件元数据而非内容，需同时配置 max、inactive、valid、min_uses 和 errors 五项参数，缺一不可，以跳过 stat()/open() 系统调用、降低磁盘元数据访问开销。
直接启用 open_file_cache 是提升 Nginx 文件检索速率最有效的方式——它不缓存文件内容，而是把“文件是否存在”“大小多少”“最后修改时间”“权限是否允许”这些高频查询结果记在内存里，后续请求直接复用，跳过 stat() 和 open() 系统调用，显著减少磁盘元数据访问开销。
核心参数必须配齐
单独写 open_file_cache 没用，以下五项需同时配置：
- open_file_cache max=10000 inactive=60s;：最多缓存 10000 个文件的元信息和句柄；60 秒内未被再次访问的条目自动清理
- open_file_cache_valid 30s;：每 30 秒主动检查一次缓存项是否仍有效（如文件是否被删或权限变更）
- open_file_cache_min_uses 2;：一个文件在 60 秒内至少被访问 2 次才进入缓存，避免冷文件占位
- open_file_cache_errors on;：把 404、403 等错误结果也缓存住，防止恶意扫描反复触发系统调用
放在合适的位置才能生效
推荐统一放在 http 块中全局启用：
✔ 正确做法：
http {<br> open_file_cache max=10000 inactive=60s;<br> open_file_cache_valid 30s;<br> open_file_cache_min_uses 2;<br> open_file_cache_errors on;<br>}
✘ 避免嵌套：不要在多个 server 或 location 中重复配置，容易引发继承冲突；若只针对静态资源，可用 location ~* \.(js|css|png|woff2)$ 隔离作用范围，但缓存本身仍是进程级共享。
配合系统限制一起调优
光配 Nginx 不够，底层资源要跟上：
- 确认
worker_rlimit_nofile足够大（建议 ≥65535），否则缓存再多句柄也打不开 - 若启用
open_file_cache_events（需 inotify 支持），检查/proc/sys/fs/inotify/max_user_watches是否 ≥ 缓存条目数 × 1.5（例如 max=10000，建议设为 15000+） - 运行
nginx -t时留意 warning，如出现 “could not build optimal open_file_cache”，说明系统限制与配置不匹配
验证效果不能只看配置加载
真实收益得靠数据说话：
- 对比开启前后：
lsof -p $(pgrep nginx) | grep REG | wc -l查看 worker 进程打开的普通文件数是否明显下降 - 压测时观察
sysstat中的%sys（系统调用开销）是否降低、%util（磁盘利用率）是否更平稳 - 如有调试版 Nginx，可开启
open_file_cache_log on，从 error_log 中查看 hit/miss 统计
