接口改不动了才开始想版本管理,已经晚了半步
第一版 API 上线时觉得"内部系统,不用搞版本"。八个月后要改字段结构,App 端老版本还在跑,删个字段都提心吊胆。那次之后,所有对外接口从第一天就带版本。
版本号放哪,常见三选一:
| 方式 | 例子 | 评价 |
|---|---|---|
| URL 路径 | /v1/orders | 最直白,调试、网关路由都方便,首选 |
| 请求头 | X-API-Version: 1 | URL 干净,但调试容易忘带 |
| 查询参数 | /orders?v=1 | 能绕过缓存,不推荐 |
什么时候开新版本——只看一条:老客户端拿到新响应还能不能正常工作。加字段(只增不改)不算破坏,随便改;改字段语义、删字段、改类型,都是破坏性变更,必须开新版本。模糊地带(比如枚举多了一个值)按"老客户端能不能容忍"来判断。
旧版本留多久:给所有调用方一个明确的截止日,过期前发三轮通知,返回头里带上 Deprecation 和 Sunset 日期。我们吃过一次亏:直接关了 v1,结果有个没人知道的脚本挂了三天。

最后一句话总结:版本管理不是技术问题,是对调用方的承诺管理。承诺给出去(接口发布)就要守,要改承诺就提前打招呼。想明白这一层,那些"路径 vs 请求头"的争论其实都无所谓。