open_file_cache需max、inactive、valid、min_uses、errors五项参数协同配置才生效，专为高频小文件缓存文件描述符及元数据（大小、mtime、错误状态等），不缓存内容，可显著降低open()/stat()系统调用开销。
open_file_cache 不是开个开关就起效的机制，它必须在 http 块（即全局 HTTP 配置层）中用五个参数协同配置，才能真正缓存文件描述符、减少 open() 和 stat() 系统调用，从而提升高频小文件（如 index.html、图标、健康检查端点）的访问效率。
它不缓存文件内容，只缓存：
- 文件描述符（fd）
- 文件大小、修改时间、权限等元数据
- “文件不存在”“权限拒绝”等错误状态（需显式启用）
✅ 必须配齐的五项参数（缺一不可）
open_file_cache 的作用依赖完整策略闭环，单独写 open_file_cache on; 完全无效：
max=N
缓存条目上限，建议按并发请求数 × 平均静态路径数预估。过高（如 >20000）可能引发共享内存锁争用。inactive=time
条目空闲超时时间。60 秒是默认值，但对高密访问场景（如/healthz），可设为20s或30s，加快复用节奏。open_file_cache_valid=time
主动校验周期。每过这个时间，Nginx 扫描缓存项，检查文件是否仍存在、mtime 是否变化。推荐30s，避免valid过长导致返回过期 404 或旧内容。open_file_cache_min_uses=N
准入门槛。同一文件需在inactive时间窗口内被访问 ≥ N 次才进缓存。设为2可过滤偶然请求；若路径极固定（如网关探针），也可设1。open_file_cache_errors on
启用错误缓存。把ENOENT（404）、EACCES（403）结果也记入缓存，防止反复触发磁盘查询。生产环境强烈建议开启。
⚠️ 注意：只要这五项都存在，缓存自动激活，无需额外写
open_file_cache on;
? 推荐的全局 http 块配置示例
http {
# 高频小文件通用型（适合静态资源服务 + 探针混合场景）
open_file_cache max=5000 inactive=60s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
# 其他必要协同配置（非 open_file_cache 本身，但影响最终效果）
sendfile on;
tcp_nopush on;
tcp_nodelay on;
# 静态资源 location 中建议关闭无关日志
log_not_found off;
access_log off;
# … 其余配置（mime、server 块等）
}? 怎么确认它真正在工作？
没有直接日志输出，但可通过系统指标验证：
查看 worker 进程打开的文件数是否收敛稳定：
lsof -p $(pgrep nginx) | wc -l
开启后应明显低于未启用时，且波动变小。对比
openat和statx系统调用次数：perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx)
理想情况下，第二次访问同文件时这两类调用应下降 50% 以上。
? 小提醒：别忽略底层配合
- 文件系统挂载建议加
noatime：mount -o remount,noatime /path，避免每次读取都更新访问时间戳。 - 若静态资源由
location ~* \.(js|css|png)$匹配，确保该块内没意外覆盖open_file_cache设置（它继承自上层http块，除非被显式重置）。
不复杂但容易忽略
