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