周日的沙龙，gosboy大哥提到了，移动应用服务器端API需要根据版本号、平台的不同物理的分离，是为了在某个版本出现问题的时候方便统计和针对性的修改（还有其他好处么？）。我想这样子是不是好多代码冗余了，那如果有个问题，很多地方都需要修改，不是要同时修改多个文件了么？
我来回答，我来回答
首先好处：
1，版本之间互不依赖。数据，配置信息，统计，等等都可以针对版本订制。往往新版发布以后，旧版本接口将不再运营，取而代之的都是更新提示等，这样就要求多版本的数据各不相同。
2，代码清晰。版本多了以后，难免出现各种判断，如果物理分离，就不需要了，各种清晰
3，我还没想到
然后代码冗余的问题：
首先，代码物理分离，但逻辑可以不分离。就是说，你要有一个BaseAPI基本满足需求，或者说可以满足1.0版本全部需求。
然后，版本API继承这个BaseAPI，最基本的版本API就是一堆继承自BaseAPI的空壳，只有当有个性化需求的时候，才去重写某些接口（方法）。
最重要的一点：版本之间一定是可继承的。也就是说，1.0继承自Base，2.0一般如果变化不大，就继承自1.0。
最后举一个较复杂的例子：
1.0继承自Base，Base是可以满足1.0全部需求的，1.0接口只是重写了版本检测等版本号以来的方法。
2.0发布，添加了一个只有2.0才支持的新功能，仅此而已。2.0接口也继承自Base，但新功能是卸载2.0里的。
2.0.1发布，修正了一些Bug。2.0.1的接口就继承自2.0接口。
3.0发布，对全部版本数据有一些较大的更新，另新增一个功能。把全部版本的更新写进Base，3.0接口继承自2.0.1，新增功能在3.0中实现
物理分离倒是不必要,冗余也有缺点的.但是版本控制是必须的.
只要能能快速的切换/回滚版本,应该就可以满足需要了.
版本镜像可以作为一个辅助手段
另外:
最好能实现版本的升降级脚本,这样子就更好了