java类不支持多重继承，故无菱形继承问题；接口多重继承可能引发default方法冲突，需通过设计约束、显式实现或委托解决，并明确static方法不参与继承解析。
Java 本身不支持类的多重继承，所以类层级中根本不会出现菱形继承问题——这是语言层面的硬性规避。真正需要关注的是接口多重继承引发的“菱形冲突”，即多个接口提供同名 default 方法时，实现类编译失败。避免它，关键不是绕开结构，而是从设计和编码两个层面主动管理。
从接口设计源头减少冲突可能
默认方法不是“必须加”，而是“值得加”。顶层接口（如 A）只应在行为确实通用、稳定且无需差异化时才提供 default 实现。如果 B 和 C 后续很可能走不同路径，A 中的方法就该保持 abstract。
- 把本该由具体实现决定的行为，提前声明为 abstract，强制子接口或实现类各自定义
- 避免在宽泛的公共接口中塞入领域特定的默认逻辑（比如 Loggable 和 Auditable 都放 default log()，就极易撞车）
- 用组合代替“伪继承”：与其让 D 同时实现 Payment 和 Notification，不如在 D 内部持有 PaymentHandler 和 Notifier 实例
在实现类中明确表态，不依赖编译器猜测
当冲突已发生（比如 D 同时 implements B 和 C，二者都从 A 继承了 default run()），Java 要求你必须写明意图。这不是负担，而是厘清责任的机会。
- 直接重写方法体：public void run() { /* 自定义逻辑 */ } —— 最清晰，适用于行为已脱离父接口语义
- 显式委托某条路径：public void run() { B.super.run(); } —— 表示“我认同 B 所代表的语义分支”，复用而非复制
- 绝不留空或仅调 super —— 编译器不接受模糊处理，必须指定具体接口名
区分 static 方法与实例方法，不混淆继承范畴
接口里的 static 方法不属于继承体系，它只是接口的工具函数，不会参与任何菱形解析。
- B 和 C 都定义 static void init()，D 可以自由定义自己的 static init()，互不影响
- 调用时必须写 B.init() 或 C.init()，语法上已杜绝歧义
- 如果类 D 的父类已有同签名实例方法，那 default 方法自动被忽略——实例方法永远优先，这是 Java 方法解析的第一规则
不复杂但容易忽略：菱形结构本身并不可怕，可怕的是让它承载了本不该统一的语义。把 default 当作契约的一部分来设计，而不是当作便利的代码补丁，冲突自然变少。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
