java接口default方法冲突是设计约束而非bug：类实现多个含同名default方法的接口时，编译器强制重写，必须用@override明确选择a.super.method()或b.super.method()等具体实现。
Java 中接口 default 方法冲突不是 bug，而是设计上的明确约束：当一个类实现多个含同名 default 方法的接口时，编译器强制你表态——不能含糊，必须显式决定行为。
必须重写，没有例外
只要两个接口（哪怕来自不同团队、不同 Jar）定义了签名完全相同的 public default 方法，而你的类同时 implements 它们，编译就会失败，报错类似：“class inherits unrelated defaults for method() from types A and B”。这不是警告，是硬性拦截。你无法靠 Spring 注解、Lombok 或构建插件绕过，因为这是 JVM 字节码生成前的语义检查。
解决方式唯一：在实现类中用 @Override 提供完整方法体。哪怕逻辑就是调用其中一个接口的默认实现，也必须写出来：
- 只写方法签名不加方法体 → 编译失败
- 方法体为空（{}）或只抛异常 → 合法，但需确认业务语义是否允许
- 直接写
A.super.method()或B.super.method()→ 最常见且清晰的做法
调用特定接口实现的语法要准确
使用 InterfaceName.super.methodName() 是唯一能访问某接口 default 实现的语法。注意几个关键点：
- 只能用于 public default 方法；static 方法和 private default 方法不参与冲突，也不能用这种语法调用
- 不能在静态上下文中使用（比如 static 方法里不能写
A.super.method()） - 可以组合调用：先执行
A.super.log()，再执行额外校验或日志增强 - 不能同时写
A.super.method()和B.super.method()而不加任何逻辑判断——那只是顺序执行，不代表“融合”，仍需说明为何这样安排
按语义选，而不是按顺手选
别因为 A.super.doWork() 一行就搞定，就默认选它。要回到业务场景问自己：
- 这个方法在这个类里，**本该承担什么职责**？比如两个接口都有
validate()，一个校验字段格式，一个校验业务状态，它们本质不同——那名字相同本身就是设计缺陷，应推动改名 - 如果语义一致（如都是“获取超时毫秒值”），但 A 返回 3000、B 返回 5000，那就需要判断当前类的上下文更倾向哪个策略，或统一取配置中心值
- 若发现多个模块反复出现同名 default 方法冲突，说明通用能力被错误地塞进了业务接口——该抽成工具类或抽象基类了
别忽略类优先和子接口优先规则
冲突不止发生在接口之间。还有两类隐性优先级会影响最终行为：
- 类优先：如果父类（或本类）已提供同名 public 方法，无论接口有没有 default 实现，都直接走类的版本，无需重写，也不触发冲突
- 子接口优先：如果接口 C extends B，且 B 和 C 都定义了同名 default 方法，那么 C 的实现会覆盖 B 的，下游实现类只看到 C 的版本
这两条规则常被误认为“能帮我省事”，其实它们只是帮你避开部分冲突场景，但一旦涉及多个并列接口（非继承关系），仍逃不开显式重写的义务。
