Java接口default方法在菱形继承中因路径不唯一引发冲突，编译器强制实现类明确选择；解决方式包括重写方法、显式调用某接口super方法或设计阶段避免default参与继承链。
Java接口的default方法在多重继承中出现菱形歧义时，编译器不会替你做选择，而是强制要求你明确表态。这不是bug，是设计上的“安全阀”——防止语义模糊导致运行时行为不可控。
冲突本质：不是接口打架，是路径不唯一
典型结构是：接口A定义default void run()；B和C都extends A且未重写run()；类D同时implements B和C。此时D处于菱形底端，两条继承路径（A→B→D 和 A→C→D）都带来同一份默认实现，JVM无法判断该走哪条路，于是报错：inherits unrelated defaults for run() from types B and C。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
三类解决方式，按需选用
-
在实现类中直接重写方法：最常用。在D里写
public void run() { /* 自定义逻辑 */ }，完全覆盖父接口行为。适合业务逻辑已脱离原始语义的场景。 -
显式调用某一方的default实现：在重写方法体内用
B.super.run()或C.super.run()委托。例如@Override public void run() { B.super.run(); }，表示“我认同B所代表的语义分支”，复用而非复制。 -
从源头避免default参与继承链：若A中的方法本就不该有统一实现（比如不同子类必须差异化处理），就声明为
abstract void run()，或干脆不加default。这样B和C必须各自实现，D自然无冲突——这是设计阶段的预防性做法。
注意边界：哪些情况不会触发冲突
static方法完全不参与继承解析。即使B和C都定义了static void run()，D可自由定义自己的static方法，或通过B.run()/C.run()显式调用，语法上已杜绝歧义。另外，若D的父类已有同签名实例方法，则所有接口default实现自动被忽略——实例方法永远优先。
