open_file_cache 通过缓存文件元数据和fd缓解高频静态资源访问的系统开销，同样适用于被HTTP请求返回的静态配置文件；必须配齐max、inactive、valid、min_uses四项参数才生效。
open_file_cache 主要缓解的是高频访问静态资源时，反复调用 stat() 和 open() 带来的系统开销，它不缓存文件内容，而是把文件是否存在、大小、修改时间、权限、甚至已打开的文件描述符（fd）记在内存里。对频繁读取的静态配置文件（比如被多个 location 或 include 指令反复加载的 conf 片段、动态路由 JSON、模板变量文件等），这项机制同样有效——只要这些文件是通过 location 或 try_files 被当作 HTTP 资源提供，而非仅在 Nginx 启动/重载时读取。
为什么静态配置文件也适用 open_file_cache
很多人误以为它只对 /static/ 下的 JS/CSS 有用，其实只要满足两个条件：一是该文件被 Nginx 作为响应体返回（即走 HTTP 处理流程），二是访问频率高、文件小、元数据查询成为瓶颈。例如：
- SPA 应用中反复请求
/config.json获取运行时参数 - 微前端架构下，每个子应用入口页都请求
/manifest.json - 前端监控 SDK 动态拉取
/feature-flag.yaml控制开关
这类请求和普通静态资源一样，每次都要查路径、验权限、读 mtime —— 正是 open_file_cache 的优化目标。
必须配齐的四个参数才真正生效
只写 open_file_cache on; 没用。它依赖以下四项协同工作，缺一不可，且需放在 http 块中：
-
open_file_cache max=10000 inactive=60s;—— 缓存最多 1 万个条目；60 秒未访问自动淘汰 -
open_file_cache_valid 60s;—— 每 60 秒检查一次缓存项是否仍有效（文件是否被覆盖或删除） -
open_file_cache_min_uses 2;—— 同一文件至少被请求 2 次才进入缓存，避免临时路径污染 -
open_file_cache_errors on;—— 把“文件不存在”“权限拒绝”等错误也缓存住，防止反复触发磁盘查找
配置建议：按静态配置的更新频率调整
配置文件不像构建产物那样长期不变，但也不像日志那样每秒写入。需平衡缓存时效性与性能：
- 若配置由 CI/CD 推送、极少手动改（如部署后 24 小时内不变）：
inactive=300s、valid=120s可减少校验压力 - 若运营后台可随时上传覆盖（如上传新
theme.css替换旧版）：valid不宜超过 10s，否则用户可能看到过期的 Last-Modified 时间，导致 304 响应误判 - 容器环境或内存受限时，
max可设为 2000～5000，配合min_uses 2避免缓存抖动
搭配 sendfile 和前缀匹配效果更稳
单独启用 open_file_cache 已有明显收益，但要释放全部潜力，还需：
- 确保
sendfile on;开启 —— 让内核直接传输文件内容，与 open_file_cache 形成“元数据+数据”双层加速 - 静态配置路径尽量用前缀匹配（如
location /config/ { ... }），避免正则匹配带来的每次请求解析开销 - 配合
try_files $uri =404;，尤其在 SPA fallback 场景下，/config.json这类路径会被高频命中，缓存效果最突出
