Java接口菱形继承不会导致运行时歧义，因编译器强制要求显式解决冲突；典型结构为A定义default work()，B和C均extends A且未重写，D同时extends B、C，此时编译报错，必须在D中重写、显式调用B.super.work()/C.super.work()或改A中方法为abstract。
Java 接口多继承中确实会出现菱形结构，但不会导致运行时歧义，因为编译器强制你当场表态——冲突不解决，代码就通不过编译。
接口菱形结构长什么样
典型结构是：接口 A 定义了 default void work()；接口 B 和 C 都 extends A，且都没重写 work()；接口 D 同时 extends B, C。这时 D 就处在“底点”，从两条路径继承了同一个默认方法，编译器会报错：
必须显式选择，不能含糊
Java 不允许“默认选某一个”，而是要求你在 D 中明确处理。可行方式有三种：
- 在 D 中直接重写
work()，提供全新实现——最常用，也最清晰 - 在 D 的重写方法里，调用
B.super.work()或C.super.work()——表示你主动选择某条继承路径的行为 - 把 A 中的
work()改成abstract（或删掉 default）——让所有下游实现类自己决定怎么做，从源头避开冲突
哪些情况不算冲突？
有些看似相似，其实不触发菱形问题：
立即学习“Java免费学习笔记（深入）”；
- 类实现多个接口，各接口都有同名 default 方法 → 编译报错，必须在类中重写
- 接口 B 和 C 没有共同父接口，但都定义了同名 default 方法 → 同样报错，D 必须覆盖
- 接口中有
static方法 → 不参与继承，B.work() 和 C.work() 可共存，D 可自由调用或重定义
设计时少留坑，比出错后补救更重要
真正稳定的接口设计习惯是：
- 公共行为尽量收敛到顶层接口，但只在必要时加 default 实现
- 中间层接口（如 B、C）专注职责扩展，避免随意覆盖父接口的 default 方法
- 如果某个方法逻辑天然存在多种解释，就别给 default，留给实现方决策
