接口升级几乎是每个有一定规模的项目都会遇到的棘手问题。接口本身并没有内置“版本隔离”的机制，但这并不意味着我们只能强行修改。实际上，通过巧妙的设计模式，完全可以让新旧两套逻辑和谐共存、各司其职。

接口本身并不直接提供“版本隔离”能力，但通过合理设计接口结构、命名规则、继承关系以及实现策略，可以间接实现不同版本功能的解耦与共存。关键在于不要给接口加版本号，而是让新旧行为互不干扰、按需调用。

通过接口拆分取代版本号标记

一种常见的做法是避免在接口名中直接包含v1、v2这类标签（比如UserServiceV2），而是按职责进行拆分。具体如何操作？

• 将通用能力（如findById、listAll）抽取为基础接口UserQueryable。
• 将新增的字段校验、异步通知等扩展能力分别定义为UserValidatable或UserNotifiable。
• 旧系统仅依赖UserQueryable；新模块则可组合多个小接口，完全无需改动原有实现。

这样一来，修改的边界就变得非常清晰了。

利用默认方法实现渐进式升级（Ja va/Go/C#）

在支持默认方法的语言中，可以在不破坏已有实现类的前提下追加能力。举个例子：

• 在原有接口中添加带有默认实现的新方法（如getDisplayName()），旧实现类自动获得兼容行为。
• 新业务类可以选择重写该方法以提供定制逻辑，旧的调用方完全不受影响。
• 需要注意：Python的ABC不支持默认方法，此时应改用组合或适配器模式作为备选方案。

使用适配器模式桥接新旧契约

当底层协议或数据结构发生不兼容变更时，适配器模式就派上用场了。它负责封装所有转换逻辑。

• 定义新接口OrderProcessorV2，包含字段paymentMethodId。
• 保留旧接口OrderProcessor，包含字段paymentType。
• 编写一个OrderV1ToV2Adapter实现OrderProcessorV2，内部调用旧服务并进行字段映射。
• 上层模块根据需要注入适配器或原生实现，完全不必感知版本差异。

根据消费者角色提供定制化接口

同一业务实体对不同的调用方，暴露的能力集可以完全不同，这天然就形成了逻辑上的“版本”隔离。

• 面向前端展示的ProductSummary接口，仅包含id、name、price。
• 面向风控系统的ProductRiskDetail接口，额外包含supplyChainTrace、certValidity。
• 这两个接口可由同一个产品服务实现，但调用方只看到自己需要的部分，互不干扰地独立演进。

总而言之，这听起来有些抽象，但本质很简单：接口隔离不是为了创建更多接口，而是为了让每个接口的职责边界清晰、调用方明确、变更影响范围可控。版本隔离的真正本质，就是控制变化的影响范围——从这个角度看，最精简的接口，就是最坚固的防火墙。