open_file_cache需配齐max、inactive、valid、min_uses和errors五项参数才生效，仅设on无效；它缓存fd等元数据以减少open/stat/close调用，不缓存文件内容。
要让 open_file_cache 真正缓存文件句柄、减少重复打开损耗，关键不是加一句 on，而是配齐参数、理解缓存对象，并匹配业务访问特征。它不缓存文件内容，只缓存 fd、大小、修改时间、存在性等轻量元数据，目标是跳过高频的 open()、stat() 和 close() 系统调用。
必须同时配置的四个核心参数
单独写 open_file_cache on; 完全无效。以下四项缺一不可，需统一放在 http 或 server 块中：
-
容量与淘汰策略：
open_file_cache max=5000 inactive=60s;—— 最多缓存 5000 个条目；60 秒内未被访问则标记为可淘汰 -
元数据校验周期：
open_file_cache_valid 30s;—— 每 30 秒主动stat()一次，检查文件是否仍存在、mtime 是否变化、权限是否有效 -
准入门槛：
open_file_cache_min_uses 2;—— 同一文件在inactive时间窗口内至少被请求 2 次才进入缓存，避免低频或临时文件污染空间 -
错误也缓存：
open_file_cache_errors on;—— 把 404（文件不存在）、403（权限不足）等结果也记入缓存，防止恶意扫描反复触发系统调用
提升句柄复用率的关键细节
缓存了 fd 不代表一定能复用，实际复用效果取决于底层支持和配置协同：
- 启用
open_file_cache_events on;（推荐），依赖内核 inotify 通知文件变更，比轮询更及时；若内核低于 2.6.27 或禁用 inotify，可关闭此项，靠valid轮询兜底 - 确保
worker_rlimit_nofile设置足够大（如 65535），否则即使缓存了 fd，进程级句柄上限也会卡住复用 - 搭配
sendfile on;使用，让内核直接传输文件内容，避免用户态拷贝，与句柄复用形成性能组合 - 静态资源 location 尽量用前缀匹配（如
location /static/），避免正则路径解析开销干扰缓存收益
按场景调整超时与阈值
默认参数适合中小规模静态服务，但不同业务需微调以平衡一致性与性能：
- React/Vue SPA 部署：首页
index.html被高频访问，建议inactive=20s、min_uses=2、valid=30s，响应更快且不积压旧缓存 - 构建后静态产物（如 CDN 场景）：文件极少变动，可设
inactive=300s、valid=120s，降低校验频率 - 灰度发布或热更新频繁：
valid不宜超过 60s，min_uses提高到 3–5，避免刚上线的新文件因访问少而进不了缓存 - 容器环境或小规格云实例：保持
min_uses=2，避免缓存抖动；max根据资源数量设为 1000–2000 即可
验证是否生效的简单方法
不依赖复杂监控，可通过日志和系统指标快速判断：
- 开启
error_log /path/to/error.log info;，观察是否有open() "/xxx" failed (2: No such file)类报错大幅减少 - 用
strace -p $(pgrep nginx) -e trace=open,stat,close抓 worker 进程系统调用，对比开启前后open()和stat()次数明显下降 - 检查
ss -s或lsof -p $(pgrep nginx) | wc -l，稳定运行后句柄总数应趋于平缓，而非随请求线性增长
