nginx的index指令按从左到右顺序匹配首个存在且可读的文件，触发内部重定向并重新匹配location；顺序决定重定向目标uri，而非最终响应内容，且仅对以/结尾的目录请求生效。
index 指令配置的多个文件不是“并行判断”，而是严格按从左到右顺序依次检查，一旦匹配到首个存在且可读的文件，Nginx 就会发起一次内部重定向（internal redirect），而不是直接返回文件内容。
内部重定向的本质是二次匹配
这不是简单的文件读取，而是触发 Nginx 请求处理流程的重新进入：找到 index 文件后（比如 index.php），Nginx 会把当前请求 URI（如 /）临时“替换成”该文件路径（即 /index.php），然后**再次走一遍 location 匹配逻辑**。
- 例如，
location / { root /var/www; index index.html index.php; }，访问/时若index.html不存在但index.php存在，Nginx 实际会以/index.php为新 URI 再次查找 location - 此时可能匹配到
location ~ \.php$，从而交由 FastCGI 处理，哪怕原始请求根本没带 .php 后缀 - 这个过程对客户端完全透明，浏览器地址栏不会变化，状态码仍是 200
顺序决定重定向目标，而非最终响应内容
index 列表的顺序，决定了“哪条路径被用来做第二次匹配”。它不控制最终用什么程序执行，只控制重定向跳向哪个 URI。
-
index index.php index.html;→ 先尝试重定向到/index.php -
index index.html index.php;→ 先尝试重定向到/index.html - 即使
index.php功能更完整，只要index.html存在且可读，就不会走到 PHP 分支
重定向依赖 root/alias 路径拼接，不是绝对路径
重定向的目标路径由 root（或 alias）+ 请求 URI + index 文件名共同构成，不是简单拼字符串。
-
root /app;+location /blog/ { index index.php; }→ 查找/app/blog/index.php，重定向目标是/blog/index.php -
alias /app/blog/;+location /blog/ { index index.php; }→ 查找/app/blog/index.php，但重定向目标仍是/blog/index.php（alias 不改变 URI） - 文件必须真实存在于拼接后的物理路径下，且 Nginx worker 进程有读取权限（如 644 权限、属组包含 nginx）
与 try_files 的协作关系
index 和 try_files 是两套独立机制，但常配合使用。index 只在请求 URI 是目录（以 / 结尾或为空）时生效；try_files 则对任意 URI 都尝试检查。
- 当用户访问
/admin（无尾斜杠），index 不触发；但try_files $uri $uri/ /admin/index.html;可补位 - 当用户访问
/admin/（有尾斜杠），index 按配置查找默认页，无需 try_files 干预 - 二者不互斥，但逻辑分工明确：index 解决“目录入口”，try_files 解决“资源兜底”
