启用 open_file_cache 可显著提升小文件访问效率，它缓存文件元数据而非内容，需配置 max、inactive、valid、min_uses 和 errors 五项参数，并配合 sendfile、前缀匹配 location 等优化才能发挥最佳效果。
直接启用 open_file_cache 是提升大量小文件访问效率最有效的方式——它不缓存文件内容，而是把“文件是否存在”“大小多少”“最后修改时间”“权限是否允许”“打不开是什么错误”这些高频查询结果记在内存里，后续请求直接复用，跳过 open() 和 stat() 系统调用。对图标、JS、CSS、index.html、健康检查路径这类小而密的资源特别管用。
必须配齐的四个核心参数
单独写 open_file_cache on; 没用，缺一不可，全部放在 http 或 server 块中：
-
容量与淘汰策略：
open_file_cache max=10000 inactive=60s;—— 最多缓存 1 万个条目；60 秒内没被访问就自动清理 -
元数据校验周期：
open_file_cache_valid 30s;—— 每 30 秒检查一次缓存项是否还有效（比如文件是否被删、改名或权限变化） -
准入门槛：
open_file_cache_min_uses 2;—— 同一文件至少被请求 2 次才进缓存，避免偶然访问污染缓存 -
错误也缓存：
open_file_cache_errors on;—— 把 404、403 等失败结果也记下来，防止反复探测同一无效路径
按业务场景调参数更稳
默认值适合日均几万到百万级请求的中小型静态服务，但你要看实际节奏来调：
- 资源极少变动（如构建后部署的 Vue/React 产物），可延长
inactive到 300s、valid到 120s，减少校验压力 - 内存充足且文件种类多（如 CDN 或大型 SPA），把
max提到 20000～50000；注意每个条目约占 1KB，别吃光可用内存 - 容器环境或磁盘 I/O 偏弱（如云上小规格实例），保持
min_uses 2，避免缓存抖动 - 后端有外部进程频繁更新文件（如动态路由 JSON），
valid不宜过大，否则可能读到过期元数据
搭配使用才能释放全部效能
单开 open_file_cache 已有明显收益，再加这几项能进一步压低系统调用和磁盘 IO：
- 确保
sendfile on;开启——让内核直接传输文件内容，不经过用户态，和open_file_cache是黄金搭档 - 静态资源
location尽量用前缀匹配（如location /static/ { }），避免正则匹配（如location ~* \.(js|png)$），减少每次请求的路径解析开销 - 在纯静态资源配置块中关闭日志：
access_log off; log_not_found off;，省掉磁盘写入开销 - 对明确不变更的路径（如
/healthz、/index.html），可在对应location块里单独启用缓存，避免影响动态路径
验证是否真正起效
没有直接日志输出，但可通过系统指标观察：
- 用
lsof -p $(pgrep nginx) | wc -l查看 worker 进程打开的文件数是否趋于稳定（开启后应明显下降并收敛） - 用
perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(pgrep nginx)对比开启前后系统调用次数（理想情况下降 50%+） - 压测时监控
%sys（系统调用开销）是否降低、%util（磁盘利用率）是否更平稳
