如果只是编写一个简单的脚本，我们很少会思考接口的兼容性问题。但如果是涉及一个大型的分布式系统，里面包括了很多微服务，服务之间相互调用，那么接口兼容性就是必须要考虑的一个因素。一个成熟产品的一个标志性特征就是对外有一套稳定的API，这里的稳定不仅指的是服务本身SLA，对服务的调用者来说，接口必须是兼容的。
比如下面的场景，服务A 调用 服务B ，当升级服务B 到新版的时候，A服务调用不受影响，这就叫向后兼容，我们在大分部开发上线的时候，都需要保持接口的向后兼容。
那么什么是向前兼容呢？ 向前意思就是向之前的接口兼容，比如我们升级了新版本，而且产生了一些数据，此时，如果我们回滚服务B，老版本的服务B 仍然可以正常提供服务。
理想状况下，我们需要做到接口的向前和向后兼容。为了保持接口的向后兼容，我们通常：
- 为类（结构体）新加字段提供默认值，保持兼容
- 绝对不要重命名或者删除字段
- 绝对不要把一个可选字段设置为必选
- 如果老的API不用了，就标记为过时
- 可以用老版本的数据，测试新接口的兼容性
如果是向前兼容，老代码遇到新字段的时候，只要做到忽略不报错即可。
现实毕竟不是理想，当我们遇到大的改动，必须升级新版本的时候。我们需要对接口有严格的版本控制。
当无法实现兼容，我们必须升级接口的版本号，比如/v1/users 升级到 v2/users 。
当只是小改动，我们可以升级一个小的版本号，比如 /v1/users 升级到 v1.1/users。
我比较建议使用上面的方式，不过社区里面也经常看到使用mine 的方式定义版本号的，比如docker镜像的格式有很多种，通过在header Content-Type里面的mine 去区分，比如下面不同格式的镜像。
application/vnd.oci.image.layer.v1.tar,
application/vnd.oci.image.layer.v1.tar+gzip,
application/vnd.oci.image.layer.v1.tar+zstd但这会让api 接口变的复杂，所以我更加推进API 版本控制。