因为类携带状态和实现细节，而行为契约只需定义“能做什么”；接口支持多实现、无状态、易Mock，配合依赖注入可动态切换实现，且Java 8+ default方法兼顾兼容性与纯行为边界。
为什么不能直接用类来定义行为契约
因为类天然携带状态和实现细节，而行为契约只需要“能做什么”，不需要“怎么存数据”或“内部怎么算”。比如定义一个 PaymentService，你只关心它有没有 pay() 方法，不关心它有没有 lastTransactionId 字段、是不是用了 Redis 缓存。用具体类做契约，等于把实现绑死——换一种支付方式就得改调用方代码，甚至动继承链。
- 类一旦被继承，子类就继承了父类的字段、构造器、非抽象方法，耦合度高
- Java 只允许单继承，如果某个类 already extends
BaseController，它就再也无法通过继承获得第二个行为契约 - 测试时难 mock：依赖具体类意味着要绕过构造逻辑、处理初始化异常，而接口变量可直接赋值 mock 实现
接口如何支撑运行时动态切换
核心在于「面向接口编程 + 依赖注入」。客户端代码只持有接口类型引用，不 new 具体实现类；真正创建哪个实现，由外部（如 Spring 容器、配置文件、工厂方法）决定。
- 例如
Loggable logger = args[0].equals("db") ? new DatabaseLogger() : new FileLogger();—— 一行判断就能切日志后端，无需改logger.log()调用处 - Spring 中用
@Qualifier("alipay") PaymentService service，配合@Bean配置多个实现，启动时自动注入指定实例 - 注意陷阱：若在类内部直接
new AlipayPayment()，就彻底破坏了这种灵活性，接口形同虚设
接口比抽象类更适合定义角色能力
一个类可以同时是“可支付的”“可退款的”“可对账的”，但这些能力彼此正交，不应强塞进同一继承树。接口支持多实现，正好表达这种“组合式角色”。
- 比如
class OrderService implements PaymentProcessor, RefundHandler, ReconciliationReport—— 清晰表达职责，不牵扯父类字段污染 - 抽象类适合表达“是什么”（如
abstract class Vehicle），接口适合表达“能做什么”（如Flyable,Swimmable） - Java 8+ 的
default方法让接口能提供通用逻辑（如logAction()），但依然禁止实例字段——这恰恰守住“纯行为”的边界
容易被忽略的兼容性细节
接口不是一成不变的契约。添加新方法会破坏所有实现类，除非用 default 或升级到 Java 9+ 的 private 辅助方法。
立即学习“Java免费学习笔记（深入）”；
- Java 7 及以前：加方法 = 所有实现类编译失败 → 必须谨慎，优先考虑新增接口（如
AsyncPaymentService） - Java 8：可用
default提供向后兼容实现，但要注意：子类可重写，且default方法不能访问实例字段 - Java 9：支持
private方法复用逻辑，但别滥用——它只是为default方法服务的，不是为了塞业务逻辑
真正棘手的是跨模块场景：你的接口被其他团队 jar 包依赖，哪怕加一个 default 方法，对方不重编译也可能因 JVM 版本差异出 NoSuchMethodError。这时候契约演进必须配套版本号和语义化发布。
