前言
梳理了接口变更的八种场景，注意好兼容性哈，大家日常开发中留言一下~~
1. 接口新增入参字段，并且有校验逻辑
我们在日常开发中，经常会遇到的需求就是，在老的接口上，新增入参，
并且需要校验
。
这时候兼容性如何处理呢？我举个简单点的例子：
比如一个用户注册接口，突然加一个
email
的字段并且不能为空,且要校验是否符合邮箱格式
其实可以
升级API版本
，比如
-
创建一个新的API版本，比如/v2/tianluo/register，在这个新版本中包含email字段，并对其进行非空校验。
如果你觉得每次新增个字段和简单校验这种情况，都要升级版本号，比较复杂繁琐，则可以将新字段email设置
为可选
。
如果客户端传了email字段，就对它校验，不传的话，直接放过，然后可以打印一下日志。
if (StringUtils.isNotBlank(userRequest.getEmail())) {
checkEmail(userRequest.getEmail());
}else {
log.info("old system request,email is null,request:{}", userRequest); }
为什么要这么做呢？
我举个例子，如果你修改了接口后，还是有老的请求，不带email字段过来的，站在业务角度，就是可以正常注册的，如果你直接校验拦截，那就有问题啦~~
2. 接口错误码调整
有些时候，我们可能需要对
接口的错误码进行调整
。
如果你调整了错误码，要及时更新接口文档，和通知上下游~~。说明错误码调整的原因。
并且要做兼容性联调测试。
比如你的分布式锁获取失败的错误码，一开始是
423000
。上游依赖这个错误码来
重试
的。
后来你做分布式锁升级优化的时候，你反手把它修改为
666000
了。如果你不通知上下游，联调测试啥的，偷偷改就不管了。那后面肯定出问题，
因为上游获取锁失败，没得重试了，依赖的错误码变更了
。。。
3. 接口返回值调整了
其是不管是
错误码调整还是返回值调整
，都是有共性的。
我们要按照三步曲去走：
比如你们的接口不是联机交易，而是MQ交互的。
你是MQ的生产者，你原来的消息体有个json格式的报文，然后，在本次需求调整了内容。你不及时做好这3步，消费端可能因为你们发版本后，消费不了这个报文(比如解析不了某个特殊返回值)。。。我们以前公司，
出过这种生产案例
，后面我在我的踩坑专栏写出来。
4. 接口参数新增、或者修改了校验
如果你的接口，原来有个字段，比如一开始最大长度是10，然后后来产品需求优化，可以增加到20。然后你觉得这个需求很简单，开开心心，花十分钟改完了，
把入参校验扩大位数，把数据库的字段长度修改
。
后来上线的时候，下游文件核对系统跑失败了。。。因为他们也会对这个字段进行最大长度是10的校验，其实这个也是我们之前遇到的一个bug。
所以做这类型需求的时候，要修改参数校验逻辑的时候。一定要考虑：
兼容性！！上下游是否会有影响等等
。
5. 接口删除，真的没请求访问了吗
有些时候，如果我们发现代码没引用，就会删掉。如果是对外接口的话，不能随手就删掉，
要确认是否还有调用
。
