open_file_cache需配齐四项参数才生效：max限制条目数、inactive设淘汰时限、valid定检查周期、min_uses防低频污染；它缓存fd和元数据而非文件内容，复用效率依赖内核inotify支持与open_file_cache_events开启。

open_file_cache 不是简单“开个开关”就能见效的功能，它本质是让 Nginx 在内存中缓存文件句柄（fd）和轻量元数据，从而跳过高频重复的 open()、stat() 等系统调用。真正起效的前提是配齐关键参数，并理解它们如何协同控制缓存生命周期与一致性。

缓存什么？不缓存什么？

它只缓存以下几类低开销信息：

• 已打开的文件描述符（fd），后续请求可直接复用，避免反复 open/close
• 文件大小、修改时间（mtime）、inode 号等元数据，省去每次 stat 调用
• 文件是否存在、是否权限不足等错误状态（需配合 open_file_cache_errors on）

它不缓存文件内容，也不替代操作系统页缓存或 Nginx 的 proxy_cache。它的价值集中在“高频小文件”场景——比如同一张图标、同一个 JS 文件被成千上万次请求时，系统调用节省效果最明显。

必须配齐的四项核心参数

单独写 open_file_cache on 没有意义。以下四项需同时存在，缺一不可：

• open_file_cache max=5000 inactive=60s：限制缓存条目上限为 5000，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（需 Linux 内核支持 inotify），Nginx 才能在文件变更时收到通知，智能决定复用或关闭 fd
• open_file_cache_valid 定期轮询校验
• 注意 worker_rlimit_nofile 配置要足够大，否则即使缓存了 fd，进程级句柄数上限也会成为瓶颈

业务适配建议：别让缓存拖慢发布

缓存太“稳”反而可能出问题，尤其在灰度发布或热更新静态资源时：

• inactive 时间应略大于该资源的平均访问间隔（例如用户页面平均停留 30 秒，则设为 45–60 秒较稳妥）
• valid 不宜超过 60 秒；设太长会导致旧文件 mtime 未及时刷新，用户看到陈旧响应
• 若资源更新频繁（如前端每日构建），建议将 min_uses 提高到 3–5，降低临时文件误入缓存概率