启用 open_file_cache 是提升静态文件吞吐最有效的底层优化之一，通过缓存文件元信息避免重复系统调用；需配置 max、inactive、valid、min_uses 等参数，并配合系统级描述符限制与 sendfile 优化。
直接启用 open_file_cache 是提升静态文件吞吐最有效的底层优化之一。它不压缩、不转发、不计算，而是让 Nginx 把频繁访问的文件元信息（路径、权限、修改时间、inode、打开句柄）缓存在内存里，避免每次请求都触发系统调用 open()、stat() 和 close()——这些操作在高并发下开销显著。
基础配置：启用并合理限制缓存范围
在 http 块中添加以下配置：
-
开启缓存：
open_file_cache max=100000 inactive=300s;—— 最多缓存 10 万个条目，300 秒内未被访问则自动淘汰 -
验证周期：
open_file_cache_valid 300s;—— 每 5 分钟检查一次缓存项是否仍有效（比如文件是否被删除或权限变更） -
最小访问频次：
open_file_cache_min_uses 2;—— 只有被至少访问过 2 次的文件才进入缓存，过滤掉一次性请求 -
错误也缓存：
open_file_cache_errors on;—— 把ENOENT（文件不存在）、EACCES（无权限）等错误也缓存起来，避免反复查不存在的路径
按文件类型差异化控制
不是所有静态文件都适合长期缓存句柄。小而常变的资源（如带版本号的 JS）可关闭句柄缓存，大而稳定的资源（如视频、PDF）应延长验证周期：
- 对图片、CSS、JS 等常规静态资源，保持默认策略即可
- 对大文件（>1MB），建议单独设置：
location ~* \.(mp4|avi|pdf|zip)$ { open_file_cache_valid 5m; open_file_cache_min_uses 1; } - 对开发环境或调试阶段的资源，可在对应 location 中显式关闭：
open_file_cache off;
配合系统级调优效果更佳
文件描述符缓存依赖操作系统层面的资源支撑：
- 确认系统文件描述符上限足够：
ulimit -n应 ≥worker_connections × worker_processes，必要时在/etc/security/limits.conf中调高 - Nginx 主配置中确保
worker_rlimit_nofile设置匹配，例如：worker_rlimit_nofile 65535; - 搭配
sendfile on;和tcp_nopush on;，让缓存后的文件读取能直接走零拷贝路径，减少内存复制
验证是否生效
可通过以下方式确认缓存正在工作：
- 观察
nginx -T输出中是否包含你配置的open_file_cache指令 - 压测时对比开启前后
iostat -x 1中的%util和r/s（磁盘 I/O 请求率）明显下降 - 查看
nginx -V是否含--with-file-aio（非必需，但支持异步 IO 时可进一步释放 worker 线程）
