Nginx的index指令触发多次stat系统调用，主要性能瓶颈在文件系统层；启用open_file_cache可缓存元数据显著降低开销；最优实践是避免目录请求，改用显式路径或结合try_files精细控制。
当Nginx配置了index指令（如 index index.html;）并请求一个目录路径（如 /assets/）时，它会尝试按顺序查找指定的索引文件。这个过程本身开销极小，但实际性能影响取决于底层文件系统行为和配置细节，而非Nginx逻辑本身。
文件系统层面的stat调用是主要开销来源
Nginx为每个index文件执行一次stat()系统调用，检查文件是否存在、是否可读、是否为常规文件。例如配置index index.html index.htm;，访问/css/将触发两次stat("/css/index.html")和stat("/css/index.htm")。在高并发或机械硬盘场景下，频繁的stat可能成为瓶颈。
- Linux ext4/xfs等现代文件系统对
stat缓存较友好，但未开启open_file_cache时仍每次发起系统调用 - 若目录下无任何索引文件，Nginx最终返回403或404，但已消耗多次系统调用
- 使用
strace -e trace=stat,openat可直观验证该行为
open_file_cache能显著降低重复开销
启用open_file_cache后，Nginx会缓存stat结果（存在性、权限、inode元信息），后续相同路径请求不再触发系统调用。
- 推荐配置：
open_file_cache max=10000 inactive=30s; open_file_cache_valid 60s; open_file_cache_min_uses 2; - 注意：该缓存不缓存文件内容，只缓存元数据；修改文件名或权限后需等待
inactive超时才刷新 - 若静态资源极少变动，可适当延长
inactive时间（如300s），进一步减少I/O
避免不必要的index查找：用显式路径替代目录访问
从性能最优角度，应尽量避免让客户端请求目录路径。直接提供完整URL（如/assets/style.css）跳过index查找全过程。
- 前端构建工具（Webpack/Vite）默认生成带哈希的静态文件名，天然规避目录索引需求
- 若必须支持目录访问（如文档站点），可配合
try_files提前终止查找：try_files $uri $uri/ =404;，比纯index更可控 - 禁用
autoindex on——它与index无关，但误开启会额外增加目录遍历开销
对比：index vs try_files 的实际差异
index仅作用于以/结尾的URI，且只在匹配到目录时生效；而try_files是通用路径回退机制，粒度更细、控制更强。
- 配置
index index.html;+ 请求/app/→ 查/app/index.html - 配置
try_files $uri $uri/index.html =404;+ 请求/app/→ 先查/app/（目录），再查/app/index.html - 后者多一次
stat（检查$uri本身），但可统一处理文件/目录/重写逻辑，适合复杂路由
