接口变更应遵循开闭原则，通过默认方法、版本化接口、适配器模式和编译期检查四步实现平滑过渡：1. 用default方法新增功能；2. 大变更采用V1/V2并行接口；3. 适配器桥接新老契约；4. @Deprecated+构建检查强制迁移。
接口变更时，所有实现类报错，本质是违反了“开闭原则”——对扩展开放、对修改关闭。直接修改接口会强制所有实现类同步改动，引发大面积编译失败和运行风险。真正可行的兼容方案，不是“一刀切升级”，而是分阶段过渡、保留旧契约、逐步迁移。
1. 接口演进：用默认方法平滑过渡
Java 8+ 支持在接口中定义 default 方法，这是最轻量的兼容手段。当需要新增功能时，不改方法签名，而是添加带默认实现的新方法；原有抽象方法保持不变，实现类无需改动即可编译通过。
- 例如原接口只有
String getName()，现需支持国际化名称，可新增default String getDisplayName(Locale locale)，提供默认返回getName()的实现 - 注意：default 方法不能覆盖 Object 类方法（如 toString），也不适用于需要强制子类重写的场景
- 避免在 default 方法中抛
UnsupportedOperationException，这等于把兼容性问题推给调用方
2. 版本化接口：并行维护旧新两套契约
当变更涉及方法删除、参数调整或语义重构（如 save(User user) → save(UserCreateDTO dto)），应引入版本化接口，如 UserServiceV1 和 UserServiceV2，而非强行改造原接口。
- 新功能走 V2 接口，旧实现类继续实现 V1；新建实现类可只实现 V2
- 通过工厂或 Spring 的
@Qualifier区分注入，避免运行时混淆 - 配合文档明确标注 V1 “Deprecated，仅维护关键缺陷”，设定下线时间表（如 3 个月后移除）
3. 适配器模式：为老实现类自动桥接新契约
若已有大量实现类无法立即重写，可在中间层加一层适配器，将新接口调用转译为对老实现类的兼容调用。
- 例如新接口要求
Result<User> createUser(CreateRequest req)，而老实现只有User createUser(String name, int age) - 编写
LegacyUserServiceImplAdapter，内部持有老实现对象，在createUser中拆解CreateRequest并委托调用 - 适配器本身实现新接口，业务代码只依赖新接口，老实现类完全隔离
4. 编译期兜底：用注解 + 构建检查控制迁移节奏
光靠设计不够，还需机制保障落地。在旧接口/方法上添加 @Deprecated，并配合构建工具（如 Maven Enforcer 或 ErrorProne）扫描未迁移的实现类，阻断不合规范的提交。
- 自定义注解如
@MigrationDeadline("2024-12-01")，配合静态检查插件提醒限期改造 - CI 流程中加入“禁止新增对已废弃接口的直接实现”规则，推动开发者转向适配器或新版接口
- 保留旧接口的 Javadoc，清晰说明替代方案和迁移步骤，降低理解成本
