Java泛型默认方法冲突源于类型擦除后签名相同，实现类必须显式重写并确保擦除后签名一致，否则编译报错；多接口同签名泛型默认方法需用Interface.super.method()明确调用。

泛型方法与默认方法本身不直接冲突，但当接口中定义了带泛型参数的默认方法，而实现类又以不同方式重写（如擦除类型、限定类型、或使用原始类型调用）时，容易因类型擦除、桥接方法生成、以及重写判定规则模糊，引发编译错误或行为异常。核心难点不在“泛型+默认”组合语法本身，而在JVM如何判断“是否构成合法重写”——这取决于签名一致性、类型参数绑定和继承链中的可见性。

泛型默认方法的重写判定规则

Java要求重写方法必须满足：方法名相同、参数数量与顺序一致、返回类型协变、且**擦除后签名完全一致**。泛型默认方法在字节码层面会被类型擦除，因此：

• 接口中声明 default <t> void process(T item)</t>，擦除后是 void process(Object item)
• 若实现类写成 public void process(String s)，这不是重写，而是重载 —— 编译器不会报错，但默认方法仍存在，调用时可能走错分支
• 若实现类写成 public <t> void process(T item)</t>，这才是合法重写；若写成 public <e> void process(E item)</e>，也合法（类型参数名可不同）
• 但若写成 public void process(Number n)，擦除后仍是 process(Object)，看似匹配，实则违反“参数类型必须精确对应擦除后签名”的规则，编译失败

多接口泛型默认方法冲突的典型场景

当两个接口各自提供泛型默认方法，且擦除后签名相同，就会触发默认方法冲突机制：

• interface Parser { default <t> T parse(String s) { return (T) s; } }</t>
• interface Validator { default <t> T parse(String s) { return (T) s.toUpperCase(); } }</t>
• class MyHandler implements Parser, Validator { } → 编译报错：“classes Parser and Validator both define method parse with same signature”
• 此时不能靠类型参数区分（如 <t extends number></t>），因为擦除后仍是 parse(String)，仍视为同签名

排查与解决的关键操作

遇到泛型默认方法相关异常，按以下顺序检查：

• 运行 javap -s -p YourInterface.class 查看泛型默认方法的签名描述符，确认擦除后的真实参数类型（如 (Ljava/lang/String;)Ljava/lang/Object;）
• 检查实现类中对应方法的字节码签名是否与之完全一致（尤其注意桥接方法是否存在）
• 避免在实现类中仅改变泛型边界（如 <t extends serializable></t>）来“试图覆盖”，这不构成重写，反而可能导致默认方法被意外保留
• 若需差异化逻辑，应在实现类中完整重写该泛型方法，并显式调用某接口的默认实现：Parser.super.parse(s) 或 Validator.super.parse(s)

为什么IDE常提示“Method does not override method from its superclass or interface”？

这个提示往往不是因为没重写，而是因为：

• 你写了 public <t> String parse(T input)</t>，但接口是 <t> Object parse(T)</t> → 返回类型不协变（String 不是 Object 的子类型？错，但 Object 是上界，String 是具体类型，此处不协变）→ 实际是返回类型不匹配
• 你在实现类中用了原始类型声明 public void parse(Object o)，但接口是 <t> void parse(T)</t> → 擦除后虽同为 parse(Object)，但编译器要求重写必须保留泛型结构，否则视为新方法
• 接口方法有 throws Exception，而实现类没声明，或声明了更具体的异常 → 违反重写契约