启用 open_file_cache 需同时配置 max、inactive、valid、min_uses 四项参数，并推荐开启 events 和调高 worker_rlimit_nofile，配合 sendfile 可显著降低磁盘 i/o 与 cpu 开销。

直接配置 open_file_cache 能让 Nginx Worker 进程复用已打开的文件描述符（fd），跳过重复的 open()、stat() 等系统调用，从而显著降低物理磁盘 I/O 和 CPU 开销。它不缓存文件内容，只缓存 fd、大小、修改时间、存在性、权限等轻量元数据——这才是减少“频繁打开损耗”的核心。

必须配齐的四个基础参数

单独写 open_file_cache on; 完全无效。以下四项需同时出现在 http 块中：

• 容量与淘汰策略：open_file_cache max=10000 inactive=60s; —— 最多缓存 1 万个条目；60 秒内未被访问即标记为待淘汰
• 元数据主动校验：open_file_cache_valid 30s; —— 每 30 秒检查一次缓存项对应文件是否仍存在、是否被修改，避免返回过期状态
• 准入门槛防污染：open_file_cache_min_uses 2; —— 同一文件需在 inactive 时间窗口内被至少访问 2 次才进入缓存，过滤偶然请求
• 错误结果也缓存：open_file_cache_errors on; —— 把 “404 文件不存在”“403 权限拒绝” 等错误状态缓存住，防止恶意扫描反复触发磁盘查询

让句柄真正复用起来的关键细节

缓存了 fd 不等于“一直开着文件”，能否高效复用取决于底层协同：

• 启用 open_file_cache_events on;（推荐），依赖内核 inotify 通知文件变更，Worker 可实时决定复用现有 fd 还是重新打开；若内核低于 2.6.27 或禁用 inotify，可关闭此项，靠 valid 轮询兜底
• 确保 worker_rlimit_nofile 设置足够大（建议 ≥ 65535），否则即使缓存了 fd，进程级句柄上限也会卡住复用
• 搭配 sendfile on; 使用，让内核直接传输文件内容，避免用户态拷贝，与句柄复用形成性能组合

按业务场景微调参数更有效

默认值适合中小静态服务，但不同访问模式需要针对性调整：

• React/Vue SPA 首页高频访问：设 inactive=20s、min_uses=2、valid=30s，响应更快且不积压旧缓存
• 构建后静态产物（如 CDN）：文件极少变动，可设 inactive=300s、valid=120s，降低校验频率
• 灰度发布或热更新频繁：valid 不宜超过 60s，min_uses 提高到 3–5，避免新文件因访问少而进不了缓存
• 容器环境或小规格云实例：保持 min_uses=2，max 设为 1000–2000 即可，避免内存和 inotify 资源争抢

验证是否真正生效的简单方法

不依赖复杂监控，可快速确认效果：

• 用 lsof -p $(pgrep nginx) | grep REG | wc -l 对比开启前后 Worker 打开的普通文件数变化
• 压测时观察 sysstat 中的 %sys（系统调用开销）是否明显下降
• 检查 error_log（需编译含 --with-debug 并启用 open_file_cache_log on;）中的 cache hit/miss 统计