Nginx 的 open_file_cache 不加速 autoindex 目录遍历，仅缓存已知静态文件的元数据（如 inode、mtime），目录列表仍需每次 readdir() 实时读取；其适用场景是高频访问的静态文件优化。
Nginx 本身不提供“目录遍历”功能（即不支持像 Apache 的 Options +Indexes 那样自动生成目录列表），所以不存在通过缓存描述符来加速目录遍历的场景。如果你启用了 autoindex on，Nginx 会实时扫描磁盘目录并生成 HTML 列表——这个过程无法被 open_file_cache 缓存，因为 open_file_cache 只缓存已知文件的元数据（如 inode、mtime、权限、打开句柄），不缓存目录内容列表。
换句话说：
✅ open_file_cache 能显著加快对已知静态文件（如 /css/app.css、/img/logo.png）的重复访问——它避免反复 stat() 和 open() 系统调用；
❌ 它不能加速 autoindex 目录列表的生成，因为每次请求 /files/ 这类路径时，Nginx 仍需执行 readdir() 系统调用读取目录项，而该操作不受 open_file_cache 控制。
如果你实际想优化的是「大量静态文件的批量访问性能」，这才是 open_file_cache 的正确发力点：
✅ 启用并调优 open_file_cache（针对文件元数据）
http {
# 缓存最多 20 万个文件描述符和元数据，60 秒未访问则淘汰
open_file_cache max=200000 inactive=60s;
# 每 30 秒检查一次缓存项是否仍有效（如文件是否被删除/修改）
open_file_cache_valid 30s;
# 同一文件至少被访问 2 次才进入缓存（避免临时文件污染）
open_file_cache_min_uses 2;
# 缓存文件不存在等错误（减少重复 stat 失败开销）
open_file_cache_errors on;
}✅ 配合 sendfile 和 tcp_nopush 减少内核拷贝
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
open_file_cache off; # 小文件频繁更新？可关闭（按需）
sendfile on;
tcp_nopush on;
tcp_nodelay on;
}✅ 对大体积静态资源（如视频、PDF）单独强化缓存
location ~* \.(mp4|avi|pdf|zip)$ {
open_file_cache on;
open_file_cache_valid 5m;
open_file_cache_min_uses 1; # 访问一次就缓存（适合大文件，IO代价高）
open_file_cache_errors on;
}如果你真需要「快速列出目录内容」，替代方案更实际：
-
预生成索引页：用脚本定期生成
index.html（如ls -lR | htmlize），作为静态文件由 Nginx 直接服务； -
禁用
autoindex，改用前端 SPA 文件浏览器（如基于 WebDAV 或 API 构建）； - 用轻量网关服务（如 Caddy）替代：Caddy 内置更智能的目录索引缓存机制。
缓存描述符不是万能钥匙，它只解决「已知路径的高频文件访问」问题。目录遍历是另一类 I/O 模式，需换思路处理。
