alias与try_files混用易致404，因alias仅一次性替换URI路径，而try_files仍按原始URI拼接检查；推荐用root替代alias，或手动用$request_filename确保路径正确。
在 Nginx 中，alias 指令与 try_files 混用时容易出错，根本原因在于二者对 URI 路径的处理逻辑存在冲突。直接套用 location + alias + try_files 的常见写法，往往导致 404 或路径拼接错误。
alias 不支持 try_files 的直接嵌套
alias 本身不参与文件存在性检查，它只做 URI 到文件系统路径的**一次性替换**；而 try_files 是按顺序检查真实文件/目录是否存在，并依赖 root 或当前上下文的根路径进行拼接。当 alias 已经重写了路径基础，try_files 后面列出的路径（如 $uri、$uri/）仍会基于原始 URI 计算，不会自动适配 alias 指定的目标目录，从而造成路径错位。
例如：
location /static/ {
alias /var/www/assets/;
try_files $uri $uri/ =404;
}
访问 /static/js/app.js 时，alias 将其映射为 /var/www/assets/js/app.js，但 try_files $uri 实际检查的是 /var/www/html/static/js/app.js（默认基于 root），必然失败。
正确做法：用 root 替代 alias（推荐）
若目标是让某个 URI 前缀对应固定磁盘目录，且需配合 try_files，优先使用 root + location 的组合，语义清晰、行为可预测：
-
root定义基础路径，location的匹配前缀会自动拼接到该路径后 -
try_files中的$uri、$uri/等变量自然基于拼接后的完整路径检查
等效写法：
location /static/ {
root /var/www;
try_files $uri $uri/ =404;
}
此时 /static/js/app.js → 检查 /var/www/static/js/app.js，符合预期。
必须用 alias 时：手动构造 try_files 路径
仅在无法调整目录结构、必须用 alias 映射到非 root 下的任意路径时，才考虑手动补全路径。关键是让 try_files 的每个选项都指向 alias 目标目录下的实际位置：
- 用
$request_filename（已由alias解析完成的真实文件路径）替代$uri - 或显式拼接
alias路径，例如/var/www/assets$uri
示例（谨慎使用）：
location /static/ {
alias /var/www/assets/;
try_files $request_filename $request_filename/ =404;
}
注意：$request_filename 在 alias 生效后才准确，且不能用于 try_files 的最后一个非 URI 参数（如 @fallback）。该方式可读性差，调试困难，应尽量避免。
其他关键细节
-
alias值末尾是否带斜杠需与location值严格匹配：如location /img/对应alias /data/images/；若location /img（无尾斜杠），则alias /data/images（无尾斜杠） -
try_files最后一个参数如果是 URI（如/index.html），会被内部重定向，此时需确保该 URI 能被其他location块处理 - 开启
log_not_found off;可减少因try_files失败产生的冗余 404 日志
