Java接口多实现能解决解耦合、提升复用性及支持组合优于继承的问题；适用于多个正交职责场景，避免抽象类单继承限制与职责污染，同时满足Spring代理、自动配置与测试Mock等框架需求。
Java接口多实现能解决什么问题
Java允许一个类同时实现多个接口，本质是为了解耦合、提升复用性，并支持“组合优于继承”的设计原则。它不提供多重继承的复杂性（比如字段冲突、构造器调用歧义），但保留了行为契约的灵活组装能力。
什么时候必须用多实现而不是抽象类
当需要给类赋予多个正交职责时，多实现比抽象类更合适。抽象类强调“是什么”，接口强调“能做什么”。比如一个类既要可序列化、又要可比较、还要可监听事件，这些职责彼此无关，强行塞进一个抽象类会破坏单一职责。
-
Serializable是标记接口，无方法，但语义关键；Comparable定义自然排序逻辑；EventListener子接口定义回调契约 —— 三者无法合理共存于同一抽象父类 - 抽象类有单继承限制，而接口可以无限叠加；
class OrderProcessor implements Runnable, Closeable, AutoCloseable是常见且合理的组合 - 接口默认方法（Java 8+）和静态方法让接口具备一定行为能力，但依然不占用类的继承槽位
多实现时方法签名冲突怎么处理
如果两个接口定义了同名同参数的方法，但返回类型不同，编译直接报错：Types of methods are incompatible；如果返回类型相同，类必须显式实现该方法，不能靠默认方法“自动合并”。
interface A { default void log() { System.out.println("A"); } }
interface B { default void log() { System.out.println("B"); } }
class C implements A, B {
@Override
public void log() {
// 必须重写，否则编译失败
A.super.log(); // 可选择调用某一方
}
}
- 若两接口方法签名完全一致（含返回类型），JVM 不关心谁先声明，只认类里的最终实现
- 若一个接口提供默认方法，另一个没有，那实现类只需覆盖有冲突的默认方法，或干脆不实现（此时用默认实现）
- 禁止在实现类中仅靠
super调用却无重写 —— 编译器会提示ambiguous reference
多实现对Spring等框架的影响
Spring 的 @Service、@Component 等注解依赖接口代理（JDK Proxy），而 JDK Proxy 要求目标对象至少实现一个接口。多实现让一个服务类既能被注入为 OrderService，又能作为 AsyncTask 或 HealthIndicator 使用，无需额外包装。
立即学习“Java免费学习笔记（深入）”；
- Spring Boot 自动配置常基于接口是否存在来判断是否启用某功能，例如实现
CommandLineRunner就会在启动后执行run() - Mockito 等测试框架依赖接口做 mock，多实现意味着可针对不同契约单独打桩，比如分别 mock
PaymentGateway和NotificationSender - 注意：若类只实现一个接口，但该接口继承多个父接口，Spring 仍视为“单接口代理”，不会自动识别父接口契约 —— 显式多实现才真正激活多契约能力
