在 nginx 中处理带参数的 url 请求时，`try_files` 默认不会将查询字符串（query string）附加到重定向的目标文件上。如果需要保留参数，必须使用 `$is_args` 和 `$args` 变量显式拼接。具体做法是在 `try_files` 的最后一个 fallback 路径后添加 `?$is_args$args`，这样当请求的文件不存在并触发内部重定向时，nginx 会自动把原始请求中的参数追加到新 uri 后面。
try_files 对静态文件的匹配逻辑是怎样的
try_files 会按顺序检查列出的文件或目录是否存在。如果找到存在的文件，则直接返回该文件的内容；如果所有列出的路径都不存在，则执行最后指定的 URI 进行内部重定向。在处理带参数的请求时，如果不做特殊处理，这个内部重定向会丢失原始的查询参数，导致后端服务无法获取参数信息。
server {
listen 80;
server_name example.com;
root /var/www/html;
location / {
# 尝试查找精确匹配的文件，然后是目录，最后是 index.html
# 关键：在最后的重定向目标后拼接 $is_args$args
try_files $uri $uri/ /index.html?$is_args$args;
}
}
上述配置中，当访问 /api/data?user=123 且服务器上没有对应的 /api/data 文件或目录时，Nginx 会将请求内部重定向到 /index.html?user=123。这里 $is_args 在存在参数时为 ?，否则为空；$args 包含完整的参数字符串。这种写法确保了 SPA（单页应用）或后端路由能正确接收到前端传递的参数。
如何区分不同扩展名的资源处理策略
对于不同类型的资源，通常希望采用不同的 try_files 策略。例如，图片、CSS 和 JS 文件可以直接由 Nginx 提供，而 HTML 页面可能需要回退到入口文件。通过为不同 location 块设置不同的 try_files 规则，可以优化缓存策略和加载行为。对于纯静态资源，不需要拼接参数，因为浏览器通常会缓存这些资源且参数对其意义不大；但对于动态内容生成的入口点，参数拼接则是必须的。
server {
listen 80;
server_name example.com;
root /var/www/html;
# 静态资源：不拼接参数，利用浏览器缓存
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
try_files $uri =404;
expires 30d;
}
# API 代理：转发给后端，保留参数
location /api/ {
proxy_pass http://backend_server;
# proxy_pass 默认保留 query string
}
# 通用 fallback：SPA 模式，保留参数
location / {
try_files $uri $uri/ /index.html?$is_args$args;
}
}
在这个多 location 示例中，静态资源请求如 /style.css?v=1 会被第一个 location 匹配，try_files 仅检查文件是否存在，不存在则返回 404，参数被忽略，这符合静态资源的常规处理方式。API 请求通过 proxy_pass 转发，Nginx 默认行为是保留 query string，无需额外操作。最后的通用 location 处理其他所有请求，确保像 /app/page?id=5 这样的请求能被正确重定向到 /index.html?id=5，供前端路由解析。这种分层处理既保证了性能，又满足了功能需求。
当 $uri 指向目录时会发生什么
当 try_files 列表中包含一个目录名（以 / 结尾）时，如果请求的 URI 与该目录前缀匹配，Nginx 会尝试在该目录下寻找 index 指令定义的文件（通常是 index.html）。如果找到了 index 文件，则返回该文件；如果没找到，且没有启用 autoindex，则返回 403 Forbidden。重要的是，这种目录匹配行为也会受到 $is_args$args 的影响。如果在目录 fallback 后拼接了参数，重定向到的 index 文件将会携带这些参数。例如，访问 /assets/ 且目录下有 index.html，若配置为 try_files $uri $uri/ /index.html?$is_args$args;，则实际返回的是 /index.html 并附带原始参数，这可能不是预期行为，需根据业务场景决定是否在目录层级也保留参数。
