java泛型类型擦除导致方法重载失效：因泛型参数被擦除为原始类型（如list和list均变为list），使不同泛型签名在字节码中重复，引发“method is already defined”编译错误；上界、下界等泛型约束不参与签名生成，故无法用于重载区分；可行替代方案是显式传入class参数或改用不同原始类型。
Java 泛型中的类型擦除会让方法重载变得不可靠，甚至直接编译失败——核心问题在于：擦除后多个泛型方法或泛型参数化的方法签名可能完全相同，而 JVM 要求同一类中不能存在签名重复的方法。
重载失效：泛型参数不同 ≠ 方法签名不同
编译器在处理泛型时，会把所有类型参数（如
-
典型报错：
Method xxx is already defined -
例子：
void handle(List<string> list)</string>和void handle(List<integer> list)</integer>擦除后都是void handle(List list)，无法共存 -
泛型方法同理：
<t> void log(T t)</t>和<u> void log(U u)</u>擦除后均为void log(Object)
边界不影响重载判断
即使你加了上界（<t extends runnable></t>）或下界（<t super string></t>），这些信息不参与擦除后的签名生成，也不用于方法分派。
- JVM 只看 descriptor（如
(Ljava/util/List;)V），不看 Signature 属性里的泛型元数据 -
void f(List extends CharSequence>)和void f(List<string>)</string>擦除后仍是同一个签名
看似重载，实则桥接或覆盖
当子类继承泛型父类并重写方法时，编译器会自动生成桥接方法来维持多态性，但这不是用户可控的重载机制。
- 例如
Generic<string></string>的set(String)会被桥接为set(Object) - 这种桥接是编译器内部补救措施，不能用来实现业务逻辑上的“按泛型类型分发”
可行的替代方案
想实现类似“按类型参数选择行为”的效果，得绕开重载依赖运行时类型信息的思路：
- 显式传入
Class<t></t>参数，用isAssignableFrom或 switch on class - 用工厂类 + Supplier 或 Function 封装类型专属逻辑
- 改用不同原始类型（如
List<string></string>vsArrayList<integer></integer>），让擦除后签名真正不同
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
