服务可以单独部署，并不代表客户端能接受它的变化。修改字段含义、删除枚举值或改变错误返回，都可能让旧客户端失效。接口兼容需要从真实消费者和迁移窗口出发设计。
先识别谁在使用接口
列出网页、移动端、合作方、脚本及内部任务，确认是否能统一控制升级时间。对无法快速升级的消费者，保留兼容窗口通常更重要。只统计代码仓库里的调用点，可能遗漏外部系统和旧版本客户端。
兼容不仅是字段还在不在
字段保留但含义改变，同样可能破坏业务。把空值、金额单位、时间格式、排序和错误语义纳入契约。新增可选字段是否安全，也需要核实消费者的反序列化行为，不能一概认为增加字段绝无影响。
用迁移顺序减少联动
先让提供方兼容新旧请求，再逐步迁移使用方，确认旧流量退出后清理。接口变更清单应同时记录观测方式和退出条件，避免兼容层无限累积。对于确实不兼容的变化，应明确新的契约入口。
验收新旧版本共存
用仍在支持期内的消费者运行关键场景，检查成功、校验失败和业务拒绝。只有正常请求通过还不够，客户端的错误处理往往更容易依赖旧结构。
常见问题：增加 v2 路径就完成版本管理了吗？
没有。仍需明确支持期、消费者迁移、数据含义和旧入口停用条件，路径只是识别契约的一种方式。
技术参考：微软：防腐层模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。