Java接口默认方法冲突需在编译期显式解决：多接口同名default方法要求实现类必须重写并可用InterfaceA.super.m()调用指定接口默认实现；若存在abstract方法则优先强制实现；Spring代理场景下未处理会导致运行时错误。
Java接口默认方法被子类重写时的语法要求
当一个类同时实现多个接口，且这些接口定义了同名同签名的 default 方法时，编译器会报错：「class inherits unrelated defaults for method」。这不是运行时问题，而是在编译阶段就必须显式解决。
必须由实现类自己提供该方法的具体实现，不能依赖任一接口的默认版本，也不能用 super 直接调用某个接口的默认方法（除非使用限定语法）。
- 不合法写法：
public void doWork() { super.doWork(); }（super在这里无意义，因为接口不是父类） - 合法写法：显式调用某接口的默认实现，如
public void doWork() { InterfaceA.super.doWork(); } - 如果只实现一个接口，且该接口有
default方法，类可直接继承，无需重写
InterfaceA.super.method() 的调用限制与场景
InterfaceA.super.method() 是唯一允许在类中调用接口默认方法的语法，但它只能出现在该类重写了该方法的上下文中，且仅限于当前类自己的方法体内。
它不是通用委托机制，不能在静态方法、lambda 或其他接口中使用；也不能跨多层继承链间接调用（比如通过另一个接口转发）。
- 只能用于解决冲突：即类已声明同名方法后，在方法体内部选择调用哪个接口的默认逻辑
- 不能省略接口名：写成
A.super.m()而非super.m() - 若接口方法是
static，则不能用InterfaceA.super.m()，而要用InterfaceA.m()
default 方法与 abstract 方法共存时的优先级规则
当一个类实现的接口中，有的提供 default 方法，有的声明 abstract 方法，且签名一致时，抽象方法强制子类实现，会“覆盖”默认方法的提供能力——此时默认方法不会生效，也不会引发冲突。
换句话说，abstract 方法具有更高契约权重，只要存在一个抽象声明，就等价于该方法在该类中必须被实现，不管其他接口有没有默认实现。
- 接口 A：
default void run() { System.out.println("A"); } - 接口 B：
void run(); // abstract
- 类 C 实现 A 和 B → 必须提供
run()实现，否则编译失败 - 此时 A 的
default run()完全被忽略，不参与冲突判定
默认方法冲突在 Spring AOP 或代理场景下的实际影响
Spring 的 JDK 动态代理基于接口，如果被代理对象实现了多个含冲突默认方法的接口，且代理类未显式处理该方法，则运行时可能抛出 AbstractMethodError 或直接调用到错误的默认实现（取决于代理生成逻辑和 JVM 版本）。
这不是 Spring 的 bug，而是 Java 语言层面对默认方法冲突的约束未被满足所致——代理类本质上也是一个实现类，同样要遵守编译期的冲突解决规则。
- 常见现象：单元测试通过，但集成到 Spring 后启动失败，报错指向某个默认方法缺失实现
- 根本原因：测试中直接 new 类实例，绕过了代理；而 Spring 创建的是代理对象，其生成的字节码需满足接
口实现语义
- 修复方式：确保目标类对所有冲突默认方法都有显式实现，哪怕只是转发给某个接口
