为了满足新的需求，接口逻辑不得不进行修改的情况下，有时候会对旧版本产生影响。
这时有如下几个办法来解决：
1.客户端强升
缺点：用户体验不好，经常强升可能会丢失部分用户。
2.后台不修改旧的接口，而是新增一个接口给客户端调用
缺点：如果这种需求多会导致接口管理混乱，接口维护过多。
3.后台考虑版本，根据版本号进行返回数据
缺点：后台接口逻辑增多，客户端版本不断增加时很老的版本判断基本已经不起多大作用了，但是又不能随便改，代码也会冗余后台同事还比较反感这种做法。
基于目前自己工作中遇到的情况总结一下，每一种都有缺点，目前团队也没固定用哪一种方案，当有这种需求的时候出现老版本不兼容客户端无能为力，有时候产品又不希望升级，让后台改他们又不爽 bug 一拖再拖基本上是拖到最后才改，到快上线的时候测试压力就比较大。
不知道大家的团队是怎么解决这个问题的，希望能沟通和指教！
然后接口改了 接口文档没改，开发换人，测试换人，想想这酸爽。。。
把线上的一台或多台机器拉下来部署新的接口，作为预发布环境，然后在这台机做回归新老版本回归测试。
在接口的入参 header 里面加上接口版本相关区分，每次发布接口可以先用临时版本，等确定没问题再切到正式版本。
根据改动量用二和三结合吧，改动大用二，改动一般用三，我们目前是这样~
接口返回时新增字段给新版客户端使用，这样不影响旧版客户端吧？
对
testly
回复
testly
回复
这样的话也就是按照客户端版本号来做兼容逻辑了。预发布环境确实能解决开发在 coding 和测试在 testing 这期间对测试结果的影响，但是策略上还有别的办法吗？
见过不少方案，如果让客户端升级，有：
- 运营手段，比如新版本才能领红包。
- 客户端能做到功能之间隔离，用到不兼容的功能时才会提示需要升级。
- 热更新。
这其实也是 Hybird 的价值之一，易变的部分用 Web 。
API 版本号，加在不同地方对于开发、测试、运维的影响也会不一样：
http://host/version3/api
http://host/api?version=3
GET /api HTTP/1.1
Accept: application/version3
GET /api HTTP/1.1
{
"version": 3
}
考虑灰度发布吧，我们也是这么做的，确定降低很多新就版本兼容的问题
