工作原因，最开始的需求其实只是希望“新版本未上线之前，审核时不影响老版本使用”，后面衍生出了“新版本接口变动能兼容老版本（不要老强更）”

由于没有其他相关的经验，就只能自己想了些办法，最开始准备了两个方案：

1. 代码中根据版本不同直接路由到不同的控制器去。
2. Nginx 中根据版本重写到不同的目录去。

最后选择 Nginx 的方案也很简单，因为如果在代码中做兼容，由于很多改动不仅涉及到控制器，可能会对 Model、Service、Event 等相关同步做调整，这时候想做兼容还是比较困难的，乃至做了修改需要新旧版本一起测。所以最后放弃这个方案，写新版本代码时直接对着新需求来写，部署时所有版本都部署一套对应版本的代码即可，然后Nginx中根据版本选择不同的目录。

而对于审核问题，之前是发布新版本后接口就已经更新了，然后才把安装包提审应用商店，但是此时由于安装包未审核通过，可能造成线上老版本用户不兼容，或者审核包无法正常使用，而同样可以利用此方案将审核包直接引导到 UAT 环境，等审核通过后，服务端这边再部署新版本，切回生产环境即可，生产包就不需要任何调整了，可以说是很方便了。

这边客户端需要做的就是始终使用 api.example.dev 作为接口地址，但请求header 头中携带客户端版本信息X-Client-Version: iOS/1.3.1.202109-101，服务器依此做识别。

具体实例代码：

# 临时维护中的提示
# return 200 '{"code":503,"message":"\u7cfb\u7edf\u6b63\u5728\u7ef4\u62a4\u4e2d,\u8bf7\u7a0d\u540e!!1"}';

# 设置默认版本(目录)
set $branch_dir 'master';

# 默认将各版本分发对应版本目录
if ($http_x_client_version ~* "^(iOS|Android)\/([0-9]+\.[0-9]+\.[0-9]+)") {
    set $branch_dir $2;
}

# 特定多个版本公用同一个版本
if ($http_x_client_version ~* "^(iOS|Android)\/(1\.[345]\.[0-9]+)") {
    set $branch_dir $2;
}

# 测试/审核版本灰度到 uat 环境
if ($http_x_client_version ~* "^(iOS|Android)\/1\.8\.0") {
    set $branch_dir 'uat';
}

# 使用对应目录的代码
root         /var/www/html/project/$branch_dir;
add_header X-App-Env $branch_dir;