try_files是nginx中实现静态资源优先、动态后端兜底的最简洁可靠方式，按空格分隔顺序检查文件或目录存在性，首个存在即返回，全不存在则内部重写至最后一个以/开头的uri或跳转至@named位置。
在 Nginx 中，try_files 是实现静态资源优先、动态后端兜底这一常见路由逻辑最简洁可靠的方式。它不依赖 rewrite 规则，不触发内部重定向，执行高效且语义清晰。
理解 try_files 的匹配逻辑
try_files 按空格分隔的顺序依次检查每个路径是否存在（对文件或目录），遇到第一个存在的就直接返回；如果全都不存在，就将请求“内部重写”到最后一个参数指定的 URI（必须以 / 开头）。
例如：
location / {
try_files $uri $uri/ /index.html;
}
表示：先找请求路径对应的文件（如 /about.js），找不到再找同名目录（如 /about/），最后都失败就返回 /index.html —— 这正是单页应用（SPA）前端路由的典型回退方案。
常见组合与实际用途
- 纯静态服务 + SPA 回退：适用于 Vue/React 构建产物部署，避免刷新 404
-
带 PHP-FPM 的混合站点：
try_files $uri $uri/ /index.php?$query_string;，让 PHP 脚本处理未命中静态资源的请求 -
多级 fallback：可链式指定多个备选，如
try_files $uri /static/$uri /fallback.html;，按需降级 -
配合命名 location 使用：最后一个参数可以是
@named，用于更复杂的逻辑分支（如日志记录、权限校验后再转发）
容易踩的坑和注意事项
try_files 的最后一个参数决定了“兜底行为”，必须明确其含义：
- 以
/开头的 URI 是内部重写，会重新匹配 location 块（注意循环风险） - 以
@开头的是命名 location，不会再次匹配，适合做最终处理 -
$uri和$uri/区别关键：前者查文件，后者查目录（末尾斜杠不可省略） - 不要在
if块中使用try_files—— Nginx 官方明确禁止，会导致不可预期行为
调试技巧：确认路径是否命中
开启 error_log 的 debug 级别（需编译时启用 --with-debug），或临时加 add_header X-Try-Files-Result "hit"; 到不同 location 中，结合浏览器开发者工具查看响应头，快速验证哪一环生效。也可用 curl -I http://localhost/path 配合 log_format 自定义日志输出实际匹配的 $uri 和 $request_filename。
