上周三凌晨两点，我被技术总监的夺命连环call薅起来。
大促预演的压测环境里，结算服务给旧版APP返回的接口里，多了个必填的优惠分摊字段。直接把占用户量12%的老版本客户端打崩了——那些都是装在千元老年机上的APP，从上线之后就没弹过升级提示，用户也懒得更。占比看着不高，架不住基数大啊，一崩就是几万笔订单付完款看不到入口，客服后台的投诉量十分钟就刷爆了。
真的疼。
总在兼容上栽的跟头 从来不是版本号没加对
出事之后大家复盘，第一反应就是“谁让你把新字段塞到老版本接口里的？加个v2版本的接口不就完了”。说这话的人，多半是没真线上踩过坑。
我见过太多团队，把接口版本兼容简单等同于URL后面加个v1、v2，或者在请求头里塞个version参数，就觉得万事大吉。实际上呢？老客户端的JSON解析容错率远低于你的想象。很多老版本客户端的解析逻辑是强校验模式，只要碰到返回值里没提前定义的字段，直接抛异常终止页面渲染，根本不会像新客户端那样自动跳过未知字段。
上次那个团队的操作就很典型：为了省写新接口的功夫，直接把原来的/v1/order/pay接口的返回结构改了，觉得老请求还是走这个地址，加个字段而已，老客户端读不到也没关系。谁知道老客户端根本没做容错，碰到陌生字段直接白屏。
先划清兼容边界 别上来就堆版本号
说实话，我特别烦那种一提到兼容就说要全量升版本的团队。你想想，要是一个加可选返回字段的小改动，你都要升个v3、v4，到最后线上同时跑着七八套接口，维护成本能把人压垮。
真要做兼容，第一步根本不是想怎么加版本号，是先把所有接口改动分成两类：一类是完全兼容的，根本不需要升版本——比如给返回值加个可选的非核心字段，给请求加个带默认值的可选参数，这些改动根本不会影响老调用方，因为人家的解析逻辑里本来就不会读这些新增的内容。另一类是不兼容的，必须升版本——比如改原有字段的类型，把可选字段改成必填，删掉原来的核心字段，改原有字段的取值规则，这些改动不管你藏得有多深，只要老请求打到这个接口，就必崩。
我之前碰到过最离谱的操作，是开发为了赶需求，直接把老接口里的gender字段从字符串”0″/”1″改成了数字0/1，还说“就是个类型调整，根本没人在意”。结果老客户端做了严格的类型判断，直接把用户中心搞崩了，全量用户加载不出头像。这种坑，谁踩谁知道。
落地的核心从来不是技术方案 是规则
很多人说微服务接口兼容难，其实难的根本不是技术实现——不管是URL带版本，还是请求头带版本，还是域名切版本，都是现成的方案。难的是你根本不知道你的老接口到底有多少人在调。
版本号是兜底手段，不是你随意修改接口的挡箭牌。我们团队现在的操作很简单，没有搞复杂的治理平台，就是列了个巴掌大的兼容检查清单，所有对外接口的改动，合并代码之前必须对着清单过一遍：有没有改原有字段的类型？有没有删字段？有没有把可选字段改成必填？只要碰了这三条，就必须走新的版本接口，不能动老版本的逻辑。
更狠一点的，我们把这个校验逻辑直接塞进了CI流程里。只要检测到老版本接口的契约有不兼容改动，直接给构建打回，不让合并。之前还有开发吐槽说流程太死板，直到上次有个哥们改了老接口的手机号字段长度，被CI拦下来，才知道这个接口还有个三年前对接的物流合作方在调，人家的老系统根本没做长度容错，要是真合上去，人家那边的物流单直接就打不出来了。
你以为接口只有你们团队自己在用？别天真了。很多你觉得早就废弃的老接口，背后可能连着三个第三方合作方、五个没升级的老客户端、甚至还有你自己团队半年前写的定时任务在调。你根本不知道哪次随意的字段改动，就会把哪个你根本没留意的系统打崩。
上次那个出事故的团队，后来花了三天时间，把所有老接口的调用方全捋了一遍，给每个接口标了兼容等级，现在大促预演的时候，再也没因为接口字段的问题出过幺蛾子。做技术哪有什么捷径，那些你觉得麻烦的流程，本质上都是之前踩过的坑堆出来的。