根本原因是JVM只认擦除后的字节码签名（descriptor），不识别泛型；多个泛型方法擦除后若descriptor相同（如<T> f(List<T>)、f(List<String>)均变为(Ljava/util/List;)V），则违反方法唯一性约束，编译直接报错。
Java 方法重载在泛型擦除后引发参数类型冲突，根本原因在于：**JVM 不认泛型，只认擦除后的字节码签名（descriptor）；而多个泛型方法擦除后若签名完全相同，就违反了“同一类中方法名+参数类型+返回类型必须唯一”的约束，编译直接报错。**
擦除让不同泛型声明变成同一个方法签名
泛型在编译期被强制擦除，不保留到运行时。比如以下三个方法：
-
<T> void handle(List<T>)→ 擦除为(Ljava/util/List;)V -
<U> void handle(List<U>)→ 同样擦除为(Ljava/util/List;)V -
void handle(List<String>)→ 也擦除为(Ljava/util/List;)V
它们在源码中看起来不同，但 javap -s 查看 descriptor 会发现三者完全一致。JVM 认为这是重复定义，编译器抛出 Method handle(List) is already defined。
看似不同的泛型边界，擦除后也可能撞车
泛型上下界不影响擦除结果的区分度，只要最终映射到同一原始类型，就仍会冲突：
立即学习“Java免费学习笔记（深入）”；
-
void process(List<? extends CharSequence>)→ 擦除为(Ljava/util/List;)V -
void process(List<String>)→ 同样是(Ljava/util/List;)V -
<T extends Number> void calc(T)和<U extends Comparable> void calc(U)都擦成(Ljava/lang/Object;)V（因无共同上界，默认上界是 Object）
这些不是“调用歧义”，而是编译期非法——连加载进 JVM 的资格都没有。
桥接方法可能悄悄加入冲突阵营
当你继承泛型类或实现泛型接口时，编译器自动生成 bridge 方法（带 bridge 和 synthetic 标记）。如果你又手动写了一个擦除后和它一样的普通方法，就会触发冲突。
- 例如：
class Child extends Pair<Date>中重写setValue(Date)，编译器会生成一个setValue(Object)的桥接方法 - 此时若你再写一个
void setValue(Object)，就和桥接方法 descriptor 完全重复 - 用
javap -c -v查看所有方法，比对 descriptor 即可定位
能共存的重载，只看擦除后参数是否真不同
只有当擦除后的参数类型在 JVM 层面可区分（即 descriptor 不同），重载才有效：
-
<T> void f(List<T>)→(Ljava/util/List;)V -
void f(ArrayList<String>)→(Ljava/util/ArrayList;)V✅ 可共存（List ≠ ArrayList） -
<K,V> void f(Map<K,V>)→(Ljava/util/Map;)V -
void f(HashMap<Integer,String>)→(Ljava/util/HashMap;)V✅ 可共存
关键不在泛型变量名或具体类型实参，而在擦除后是否落到不同的原始类型上。
