通过配置 try_files 指令，让 nginx 优先尝试匹配新版本的文件路径，若不存在则回退到旧版本，从而实现平滑升级。具体做法是在 location 块中设置 $uri/ 为第一优先级，并在其后追加带有版本号后缀的路径（如 /v2$uri/），最后以 @old 或旧版路径作为兜底。这样在部署新包时，只需将文件放入新版目录，nginx 会自动将流量切换至新文件，无需重启服务。
如何配置 try_files 实现新旧版本回退
配置的核心在于利用 try_files 的顺序执行特性，先检查新版本是否存在，再检查旧版本。例如，对于静态资源请求，可以设置 try_files $uri /v2$uri @old;。当请求 /app.js 时，Nginx 首先查找当前目录下的 /app.js，如果找不到（即正在使用旧版本或未部署新文件），则尝试查找 /v2/app.js。如果新版也不存在，则通过内部重定向 @old 指向旧版本的逻辑或直接返回错误。这种机制允许运维人员在不停机的情况下，逐步将新文件推送到指定目录，流量会自然过渡到新文件。
server {
listen 80;
server_name example.com;
root /var/www/html/current;
location / {
# 1. 尝试当前目录（通常是旧版本或待替换区）
# 2. 尝试 v2 目录（新版本）
# 3. 如果都不存在，尝试 index.html
try_files $uri /v2$uri /index.html =404;
}
# 可选：定义旧版本的重定向标签，用于更复杂的回退逻辑
location @old {
root /var/www/html/old;
try_files $uri /index.html =404;
}
}
在上述配置中，/var/www/html/current 是 Nginx 的根目录。假设旧版本文件位于此处，而新版本文件被上传到 /var/www/html/v2。当新版本文件 /var/www/html/v2/app.js 存在时，try_files 的第二项匹配成功，Nginx 直接读取该文件。此时，旧版本的 /var/www/html/current/app.js 可以被安全删除或保留，不影响新流量的访问。如果新版本文件尚未上传，请求会回退到第一项，继续提供旧版本服务。这种“双目录”策略是无缝切换的关键。
如何处理动态路由和 API 请求的版本切换
对于非静态文件的动态请求，如 API 接口或 SPA 应用的路由，try_files 同样适用，但需要结合后端代理或特定的重写规则。例如，在处理 Vue 或 React 应用的客户端路由时，通常希望所有未知路由都返回 index.html。在版本升级场景下，可以配置 try_files $uri $uri/ /v2$uri /v2$uri/ /v2/index.html =404;。这表示 Nginx 会依次检查：当前 URI 对应的文件、当前 URI 对应的目录、新版 URI 对应的文件、新版 URI 对应的目录、新版根目录下的 index.html。这种配置确保了无论用户访问哪个子路径，只要新版中有对应资源，就会优先加载新版内容。
server {
listen 80;
server_name app.example.com;
root /var/www/spa/current;
location / {
# 优先尝试当前版本的文件和目录
# 其次尝试 v2 版本的文件和目录
# 最后尝试 v2 版本的 index.html 作为入口
try_files $uri $uri/ /v2$uri /v2$uri/ /v2/index.html =404;
}
# API 请求代理示例
location /api/ {
proxy_pass http://backend_v2:8080/;
# 注意：API 通常不依赖 try_files，而是直接代理
# 但如果需要灰度发布，可在此处根据 header 或 cookie 决定代理目标
}
}
在这个例子中，/var/www/spa/current 存放旧版前端代码，/var/www/spa/v2 存放新版。当用户访问 /dashboard 时，Nginx 首先检查 /var/www/spa/current/dashboard 是否为文件或目录，如果不是，再检查 /var/www/spa/v2/dashboard。如果新版中也没有这个特定路径，最终会命中 /v2/index.html，由前端框架接管路由渲染。这种方式保证了 SPA 应用在版本切换时的完整性，避免了因路由缺失导致的 404 错误。同时，API 请求通常独立于静态文件，可以通过负载均衡器或 Nginx 的 proxy_pass 直接指向新的后端服务实例，实现前后端分离的无缝升级。
基于 try_files 回退机制的具体问题：当新旧版本文件都存在时，流量如何分配？
当新旧版本文件同时存在于各自的目录中时，try_files 的行为完全取决于配置的顺序。由于我们配置的是先检查当前目录（旧版），再检查新版目录，因此默认情况下，流量会继续流向旧版本文件，直到我们将旧版本文件删除或重命名。要实现立即切换，需要在部署新版后，手动移除旧版对应文件，或者修改 try_files 的顺序，将新版目录放在前面。例如，将配置改为 try_files /v2$uri $uri/ /index.html =404;，这样 Nginx 会优先加载新版文件，即使旧版文件仍然存在。这种灵活性允许运维人员根据业务需求选择“渐进式”还是“即时”切换策略。
