try_files顺序决定成败，因Nginx严格按序查找：先$uri（文件）、再$uri/（目录索引）、最后/index.html（SPA入口）；顺序颠倒或缺失任一环，将导致子路由404或API被错误回退。
为什么 try_files 的顺序决定前端路由和资源加载成败
单页应用（SPA）部署在 Nginx 时，如果只配 try_files $uri $uri/ =404，刷新页面或直接访问子路由（如 /user/profile）会返回 404——因为 Nginx 按顺序查找物理路径，没匹配就终止。关键在于：Nginx 不会自动把所有非 API 请求兜底到 index.html，必须显式声明回退链。
正确做法是把静态资源优先级放在最前，再逐级 fallback 到入口文件：
location / {
try_files $uri $uri/ /index.html;
}
这行配置的含义是：先查真实文件（$uri），再查目录索引（$uri/），最后才回退到 /index.html。顺序不能颠倒，否则 /api/user 这类真实接口可能被错误重写到 HTML。
如何避免 try_files 把 API 请求也兜底到前端
常见错误是把所有请求都扔给 index.html，导致后端 API 返回 HTML 内容而非 JSON。必须用独立 location 块隔离接口路径。
立即学习“前端免费学习笔记（深入）”；
- 若 API 在
/api/下，需提前匹配并 proxy_pass，确保不进入主try_files链 -
location ^~ /api/比location /优先级高，能截断匹配 - 不要在
location /api/里写try_files，它不该参与前端回退逻辑
示例：
location ^~ /api/ {
proxy_pass http://backend;
proxy_set_header Host $host;
}
location / {
try_files $uri $uri/ /index.html;
}
多级回退时 $uri/ 和 /index.html 的实际行为差异
$uri/ 触发的是目录索引查找（比如请求 /static/css/，Nginx 会找 /static/css/index.html），而 /index.html 是绝对路径回退，不管原始 URI 是什么。两者不可互换。
- 漏掉
$uri/：访问目录路径（如/assets/）会直接 404，而不是尝试该目录下的index.html - 误写成
/：try_files $uri $uri/ /会导致所有未命中请求重定向到根，可能触发浏览器跳转而非内部重写 - 加
=404放最后：仅当明确不想 fallback 时使用，SPA 场景下通常不需要
Vue/React 项目中 try_files 配合 base URL 的坑
如果前端构建时设了 publicPath 或 base（如 /app/），Nginx 的 try_files 路径必须与之对齐，否则资源 404。
- 构建输出路径为
/app/index.html，则try_files应写/app/index.html，不是/index.html - 对应地，
location也应匹配前缀：location /app/ { try_files $uri $uri/ /app/index.html; } - 若用
alias，注意它会替换整个路径，try_files中的/app/index.html必须与 alias 指向的物理路径一致
最稳妥的方式是统一用 root + 相对路径，避免 alias 的路径拼接陷阱。
回退链看着简单，但每级都依赖真实文件系统结构和前端构建配置的严格对齐；少一个斜杠、错一个前缀，资源就断在半路。
