Java泛型方法签名冲突源于类型擦除导致JVM签名重复，解决关键是避免擦除后重载冲突：用语义化方法名替代泛型区分、抽取共用逻辑到私有方法、规避桥接方法干扰、使用Class<T>运行时分发、或按职责拆分接口。
Java 中泛型方法签名冲突的根本原因，是编译后类型擦除让多个方法变成完全相同的 JVM 签名（如 void process(List)），而 JVM 不允许同名、同参数类型、同返回类型的重载方法共存。解决的关键不是“对抗擦除”，而是从设计上避开擦除后的签名重叠。
用语义化方法名替代仅靠泛型区分
泛型参数本身不能作为重载依据。写两个 process(List<string>)</string> 和 process(List<integer>)</integer> 会直接编译失败，因为擦除后都是 process(List)。
- 改用职责明确的名称：比如
processUserNames(List<string>)</string>和processOrderIds(List<integer>)</integer> - 把重复逻辑抽到私有方法中，例如
private void doProcess(List> list)，对外只暴露语义清晰的公有入口 - 这样既避免编译错误，又提升可读性，IDE 跳转和补全也更准确
检查并规避桥接方法干扰
继承泛型类或实现泛型接口时，编译器会自动生成桥接方法（带 bridge 和 synthetic 标记）。如果你手动写了擦除后签名相同的公开方法，就会冲突。
- 用
javap -c -v YourClass查看字节码，重点关注descriptor行（如(Ljava/util/List;)V） - 若你写的某个方法 descriptor 和桥接方法一致，就删掉或重命名该方法
- 典型例子：子类重写
<T> void set(T)后，编译器生成void set(Object)桥接方法；此时再定义一个void set(Object)就会报错
改用类型令牌（Class<T>）做运行时分发
当多个操作逻辑相似但目标类型不同，又必须统一入口时，放弃重载，改为接收 Class<T> 参数，在运行时判断并分发。
立即学习“Java免费学习笔记（深入）”；
- 声明为
<T> T handle(String data, Class<T> type)，擦除后是Object handle(String, Class)，无签名冲突 - 内部可用
type.cast()或Gson.fromJson(json, type)安全转换 - 适合通用解析器、配置加载、跨模块数据适配等需要灵活支持多种目标类型的场景
换设计思路：委托或拆分接口职责
如果问题出现在实现多个泛型接口（如同时实现 Processor<String> 和 Validator<Long>），且它们都有 handle(T)，擦除后全变成 handle(Object)，说明接口抽象粒度不够。
- 按语义拆成独立方法：如
processString(String)和validateLong(Long)，再由各自接口的默认方法或包装类调用 - 引入非泛型委托层：定义一个
Handler接口，内部持有具体类型的处理器实例，把类型分发逻辑移到运行时 - 这样既解耦了类型依赖，又让每个方法签名在编译期唯一
