try_files 本身不支持灰度切换，但可通过 map 或 split_clients 预设变量（如 $static_prefix 或 $env_route），结合 try_files 按序尝试对应版本路径实现 Cookie 驱动或概率型灰度分发，并配合 rewrite 统一入口与兜底。
try_files 本身不支持灰度切换，但它能配合变量动态拼路径，再结合 map 或 split_clients 等指令，实现基于静态资源的多环境（如 v1/v2/staging）灰度分发——关键是把“环境选择”逻辑前置为变量，让 try_files 按顺序尝试对应目录。
用 map + try_files 实现 Cookie 驱动的版本路由
适合定向灰度（如内部员工、白名单用户），通过 Cookie 决定加载哪个版本的前端包。
- 在 http 块中定义 map，根据 cookie 值映射出路径前缀：
map $cookie_env $static_prefix {
"staging" "/staging";
"v2" "/v2";
default "/v1";
}- 在 location /static/ 中使用该变量做路径回退：
location /static/ {
root /var/www/frontend;
try_files $static_prefix$uri $static_prefix$uri/ /v1$uri =404;
}例如用户带 Cookie: env=v2，Nginx 会依次检查：
→ /var/www/frontend/v2/js/app.js
→ /var/www/frontend/v2/js/app.js/（目录）
→ /var/www/frontend/v1/js/app.js（兜底）
路径拼接必须与 root 目录结构严格匹配，否则 404。
用 split_clients 实现概率型灰度（A/B 测试）
适合渐进式验证新包稳定性，按请求 ID 或随机值分配固定比例流量到不同环境。
- 先生成一个稳定标识（如 $request_id 或 $remote_addr）用于分流：
split_clients "$request_id" $env_route {
5% "staging";
10% "v2";
* "v1";
}- 再在 location 中复用该变量：
location /static/ {
root /var/www/frontend;
try_files /$env_route$uri /$env_route$uri/ /v1$uri =404;
}注意：split_clients 的百分比是哈希后长期稳定的，同一请求 ID 总走同一环境，利于调试和问题追踪。
立即学习“前端免费学习笔记（深入）”；
配合 rewrite 实现 URL 无感迁移与兜底
当新旧版本路径结构不一致（如 /dist/ → /assets/），可用 rewrite 统一入口，再由 try_files 分层兜底。
- 例如将所有 /static/ 请求重写为内部路径，再按环境尝试：
location ^~ /static/ {
rewrite ^/static/(.*)$ /$1 break;
try_files /v2/$1 /v1/$1 /fallback/$1 =404;
}这样 /static/js/app.js 会被重写为 /js/app.js，然后依次查找 v2/js/app.js → v1/js/app.js → fallback/js/app.js。rewrite 后必须用 break，避免循环；try_files 中的 $1 是 rewrite 捕获的路径片段。
关键注意事项
- 所有路径都相对于 root，不要漏掉开头的 /；alias 和 root 行为不同，静态资源推荐用 root
- 确保各版本目录真实存在且 Nginx 用户有读取权限（如 chown -R www-data:www-data /var/www/frontend/v2）
- 开启 access_log 和 error_log，加 log_format 记录 $version_prefix 或 $env_route，便于排查未命中原因
- 前端 HTML 中引用资源时保持路径统一（如 /static/js/app.js），不硬编码版本前缀，由 Nginx 层控制
