open_file_cache通过缓存文件元数据显著提升高频静态资源配置项读取性能，避免重复系统调用；核心参数包括max、inactive、valid、min_uses和errors；需按资源类型差异化配置，并可通过lsof、strace等验证效果。
直接用 open_file_cache 缓存文件元数据，而不是反复调用系统接口读取文件状态和内容——这是优化高频静态配置项（如频繁访问的 JS/CSS/图片、证书、密钥、配置片段等）读取性能最有效的方式。
为什么 open_file_cache 能显著提速
当 Nginx 每次响应请求都要打开、检查、读取同一个静态文件（比如 logo.png 或 app.css），操作系统会反复执行 stat()、open()、read() 等系统调用。这些操作虽小，但在高并发下会成为瓶颈。open_file_cache 把文件描述符、最后修改时间、权限、大小等元数据缓存在内存中，后续请求可直接复用，省去磁盘 I/O 和内核态开销。
核心配置参数说明
在 http 块中启用并调优：
- open_file_cache max=10000 inactive=60s;：最多缓存 10000 个文件句柄，60 秒内未被访问的条目自动清理
- open_file_cache_valid 30s;：每 30 秒检查一次缓存项是否仍有效（例如文件是否被删或改）
- open_file_cache_min_uses 2;：一个文件至少被访问 2 次才进入缓存（避免缓存冷门文件）
- open_file_cache_errors on;：把“文件不存在”“权限拒绝”等错误也缓存起来，避免重复报错
按资源类型差异化启用
不是所有静态资源都适合统一缓存。建议分场景控制：
- 对稳定不变的小文件（如带哈希的 JS/CSS、字体、图标）：全局开启，且可适当延长
inactive时间（如 120s） - 对可能热更新的大文件（如 PDF、视频封面图）：单独 location 中关闭缓存，避免 stale 元数据导致 404 或旧内容残留：
open_file_cache off; - 对敏感配置类文件（如 TLS 证书、密钥路径）：确保
open_file_cache_valid足够短（如 10s），便于快速感知证书轮换
验证是否生效
重启 Nginx 后，可通过以下方式确认：
- 用
lsof -p $(pgrep nginx)查看 worker 进程打开的文件数是否趋于稳定（不再随请求数线性增长） - 配合
strace -p $(pgrep nginx) -e trace=open,stat观察系统调用频率明显下降 - 查看 Nginx error 日志，若出现
open() "/path/to/file" failed (2: No such file or directory)且后续不再重复出现，说明open_file_cache_errors on已起作用
不复杂但容易忽略。它不改变响应内容，却能让万级 QPS 下的文件访问延迟下降 30% 以上。
