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，而实现类没声明，或声明了更具体的异常 → 违反重写契约
