Java类实现多个含同名同参默认方法的接口时，必须显式覆盖该方法，否则编译报错；若返回类型不同则接口定义非法；static方法不参与继承，只能通过接口名调用。
Java类实现多个接口时，方法签名冲突怎么处理
当一个类同时实现 InterfaceA 和 InterfaceB，而两者都定义了同名同参的默认方法（比如 default void log()），编译器会直接报错：class inherits unrelated defaults for log() from types InterfaceA and InterfaceB。这不是运行时问题，是编译期强制拦截。
必须由实现类显式覆盖该方法——哪怕只是调用其中一个父接口的实现。不写就是编译失败。
- 不能只靠
super.InterfaceA.log()就完事，得写完整方法体 - 如果两个接口的方法签名完全一致但返回类型不同（比如一个返回
String，一个返回int），根本无法共存，Java 不允许这种接口设计 - 静态方法不会冲突，因为不能被继承，只能通过接口名调用：
InterfaceA.staticMethod()
接口里 default 方法和 static 方法的实际调用边界
default 方法能被实现类对象调用，但不能被接口引用变量直接调用（除非该变量实际指向实现类实例）；static 方法只能通过接口名调用，和类的静态方法一样，跟实现类无关。
常见误用：在实现类里试图用 this.staticMethod() 或 super.staticMethod() 调用接口静态方法——这会编译报错：non-static method cannot be referenced from a static context（即使写在非静态方法里也不行）。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
default方法可以访问this，能调用其他default方法或抽象方法 -
static方法不能访问this，也不能访问接口里的其他default方法 - 若两个接口都有同名
static方法，实现类完全不受影响——因为它们压根不参与实现类的继承链
为什么不能用抽象类替代多接口来“绕开限制”
抽象类确实支持单继承下的部分实现，但它无法解决“一个类需要具备多种正交能力”的问题。比如你要让 PaymentProcessor 同时具备 Retryable、Loggable、Validatable 行为——这些职责本就不该耦合进同一个抽象基类。
强行用抽象类聚合，会导致：子类被迫继承无用字段、模板方法被滥用于不相关逻辑、未来想换掉某项能力（比如把日志从 Log4j 换成 SLF4J）就得改抽象类甚至所有子类。
- 接口定义契约，抽象类定义模板——混用就模糊了意图
- Java 8+ 的
default方法不是为了让你写业务逻辑主干，而是补足“接口演进时不破坏现有实现” - 如果发现多个接口总是一起被实现，说明可能缺一个组合接口，比如
public interface RobustProcessor extends Retryable, Loggable, Validatable
IDEA/Eclipse 中快速识别接口方法来源的技巧
光看实现类代码，很难一眼分清某个方法是来自哪个接口，尤其当多个接口有相似 default 实现时。鼠标悬停在方法调用处，IDE 通常只显示签名，不标来源。
真正管用的是：按住 Ctrl（Windows/Linux）或 Cmd（macOS）再点击方法名——它会跳转到**最具体的定义处**。如果是实现类自己写的，就跳到类里；如果是 default 方法，就跳到对应接口；如果跳转失败，说明是抽象方法，得去接口声明处找 void methodName(); 这行。
- 别依赖“Find Usages”，它会列出所有重写/实现位置，信息过载
- 检查
@Override注解是否真有对应父级声明——有时候只是手误写上去的 - Gradle/Maven 编译失败时，错误行号往往指向接口文件，不是你的实现类
default 当成“可选实现”而忽略其强制覆盖规则——Java 在这儿没留商量余地。 
