接口不直接提供版本隔离，但可通过拆分职责、默认方法、适配器和按角色定制等策略实现新旧功能解耦共存，核心是控制变化影响范围。
接口本身不直接提供“版本隔离”能力，但可以通过合理设计接口结构、命名、继承关系和实现策略，间接达成不同版本功能的解耦与共存。关键不是给接口加版本号，而是让新旧行为互不干扰、按需选用。
用接口拆分替代版本标记
避免在接口名中硬编码 v1、v2（如 UserServiceV2），而应按职责或能力维度拆分：
- 把通用能力（如
findById、listAll）抽成基础接口UserQueryable - 把新增字段校验、异步通知等扩展能力单独定义为
UserValidatable或UserNotifiable - 旧系统只依赖
UserQueryable；新模块可组合多个小接口，无需修改原有实现
通过默认方法支持渐进升级（Java/Go/C#）
在语言支持默认方法的前提下，可在不破坏已有实现类的前提下追加能力：
- 在原有接口中添加带默认实现的新方法（如
getDisplayName()），老实现类自动获得兼容行为 - 新业务类可选择重写该方法以提供定制逻辑，不影响老调用方
- 注意：Python 的 ABC 不支持默认方法，需改用组合或适配器模式
用适配器桥接新旧契约
当底层协议或数据结构发生不兼容变更时，用适配器封装转换逻辑：
- 定义新接口
OrderProcessorV2，含字段paymentMethodId - 保留旧接口
OrderProcessor，含字段paymentType - 编写
OrderV1ToV2Adapter实现OrderProcessorV2，内部调用旧服务并做字段映射 - 上层模块按需注入适配器或原生实现，不感知版本差异
按消费者角色提供定制接口
同一业务实体对不同调用方暴露不同能力集，天然形成逻辑“版本”隔离：
- 面向前端展示的
ProductSummary接口只含id、name、price - 面向风控系统的
ProductRiskDetail接口额外包含supplyChainTrace、certValidity - 两者都可由同一个产品服务实现，但调用方只看到自己需要的部分，互不影响演进
不复杂但容易忽略：接口隔离不是为了造更多接口，而是让每个接口背后的责任清晰、使用者明确、变更边界可控。版本隔离的本质，是控制变化的影响范围——而最小接口就是最有效的防火墙。
