泛型方法重载冲突的根本原因是类型擦除导致编译后字节码签名相同，JVM禁止同名、同参数、同返回类型的方法共存；应使用语义化方法名、避免泛型参数区分重载，并检查桥接方法是否重复。
泛型方法重载冲突的根本原因不是代码写错了，而是 Java 的类型擦除机制让多个看似不同的方法在编译后变成完全相同的字节码签名（descriptor），而 JVM 不允许同名、同参数类型、同返回类型的方法共存。
看清擦除后的实际签名
别只看源码里写了 List 还是 List——编译后它们都变成 List。同样， void f(U) 擦除后都是 void f(Object)。
- 用
javac YourClass.java编译后，再运行javap -s YourClass - 重点看每行的
descriptor:字段，比如(Ljava/util/List;)V或(Ljava/lang/Object;)V - 如果两个方法的 descriptor 完全一样，就必然冲突，和泛型变量名（
T/U）无关
用语义化方法名代替泛型重载
泛型本就不该用来区分重载，职责才是命名依据。这是最直接、安全、可读性强的解法。
- ❌ 错误写法：
process(List/) process(List) - ✅ 正确写法：
processNames(List/) processIds(List) - 若逻辑相似，可提取公共私有方法统一处理，对外暴露清晰接口
检查桥接方法是否意外叠加
继承泛型类或实现泛型接口时，编译器可能自动生成桥接方法（bridge method）。你手动写的某个方法若擦除后与之相同，就会冲突。
- 运行
javap -c -v YourClass，查找带bridge和synthetic标记的方法 - 比对这些桥接方法的 descriptor 是否和你自己写的某个方法重复
- 如有重复，删掉手动写的那个，或改名/改参，让编译器生成的桥接方法能正常工作
换设计思路：委托或类型令牌
当多个接口方法擦除后撞车（比如同时实现 Processor 和 Validator，都有 handle(T)），硬重载走不通，就得重构协作方式。
- 把不同语义的操作拆到不同方法，如
onProcess(String)+onValidate(Long) - 用委托模式：定义一个通用处理器，接收类型令牌（如
Class）做运行时分发 - 避免仅靠泛型参数区分重载——Java 不支持，也不应依赖
