java接口同名default方法冲突时编译报错，必须在实现类中显式重写并用interfacename.super.methodname()调用特定接口的default实现。
Java接口同名默认方法冲突时编译报错
当一个类同时实现两个接口，而这两个接口都定义了同签名的default方法（比如都叫log()），Java编译器会直接拒绝编译，报错信息是：class inherits unrelated defaults for log() from types A and B。这不是运行时问题，而是编译期强制拦截——Java不打算替你做选择。
常见错误现象：明明没写任何方法体，只写了implements A, B，却编译失败；或者升级第三方库后突然编译不过，大概率是它们的接口悄悄加了同名default方法。
- 必须在实现类中**显式重写**该方法，哪怕只是调用其中一个父接口的实现
- 不能只写方法签名不写方法体，也不能用
super模糊调用（如A.super.log()必须明确指定接口） - 如果两个接口的
default逻辑本质不同（比如一个打日志到控制台，一个发监控埋点），强行复用某一方容易埋下行为偏差
解决冲突必须显式调用特定接口的default实现
重写时若想保留某一方逻辑，得用InterfaceName.super.methodName()语法。这是唯一合法调用父接口default方法的方式，this或super单独用都不行。
使用场景：你信任LoggingInterface的format()逻辑，但MetricsInterface也提供了同名default format()，而你不想自己重写格式化逻辑。
立即学习“Java免费学习笔记（深入）”；
public class ServiceImpl implements LoggingInterface, MetricsInterface {
@Override
public String format() {
return LoggingInterface.super.format(); // 必须写全接口名
}
}
- 不能写成
super.format()——编译报错call to super must be interface name - 如果未来
LoggingInterface删掉default format()，这里不会自动降级为抽象方法，而是直接编译失败（提醒你补实现） - 多个接口提供同名
static方法不影响，因为static不参与实现继承，调用时必须带接口名
default方法冲突与抽象方法、静态方法的边界区别
只有default方法会触发这种多实现冲突；抽象方法只要求子类实现一次，static方法根本不会被继承。但三者混用时容易误判责任归属。
参数差异：抽象方法和default方法签名一致时，子类实现会同时覆盖两者；但static方法即使签名相同，也只是“同名不同源”，互不影响。
- 如果接口A有
abstract void run()，接口B有default void run()，实现类仍必须提供run()体（抽象方法优先级更高） - 如果两个接口都有
static void init()，类里可以完全不管，调用时必须写A.init()或B.init() - 性能上无差异——
default方法编译后就是普通实例方法，没有额外虚调用开销
Spring等框架中隐式实现接口可能放大冲突风险
像org.springframework.data.repository.CrudRepository这类接口自带大量default方法，一旦你的DAO接口也定义了save()或findAll()的default实现，和Spring的同名方法一碰就炸。
兼容性影响：JDK 8引入default本意是向后兼容，但实际让接口演进变得更敏感——加一个default可能无声破坏下游实现类。
- 检查依赖的三方接口是否新增
default方法（看release note或反编译.class） - 避免在自定义接口里随便加
default方法，尤其当它可能被广泛实现时 - IDE通常会在实现类报红时提示“implement methods”，但不会告诉你冲突来自哪个接口——得手动点开两个接口源码比对方法签名
最麻烦的不是写几行重写代码，而是得确认两个同名default方法的行为是否真的可互换。有时候它们名字一样，做的事却南辕北辙。
