Java泛型方法签名冲突源于类型擦除后字节码签名重复，解决需避开擦除冲突：用语义化命名替代泛型重载、规避桥接方法干扰、以Class<T>作运行时分发、按职责拆分接口方法。
Java 中泛型方法签名冲突的根本原因不是写法错误，而是类型擦除后多个方法在字节码层面拥有完全相同的签名（如 (Ljava/util/List;)V），JVM 不允许同名、同参数类型、同返回类型的重载方法共存。解决的关键不是“对抗擦除”，而是从设计上避开擦除后的重复。
用语义化命名替代泛型参数区分
不要依赖 T 或 U 的不同来重载方法，因为擦除后它们都变成 Object 或原始类型。例如：
- ❌ 错误：两个方法
process(List<String>)和process(List<Integer>)编译失败——擦除后都是process(List) - ✅ 正确：改用职责明确的名称，如
processUserNames(List<String>)和processOrderIds(List<Integer>) - 共用逻辑可提取为私有方法（如
doProcess(List<?> list)），对外只暴露清晰、不可混淆的公有接口
检查并规避桥接方法干扰
当类继承泛型父类或实现泛型接口时，编译器会自动生成桥接方法（标记为 bridge 和 synthetic）。如果你手动写的某个公开方法擦除后与其一致，就会冲突。
- 用
javap -c -v YourClass查看字节码，重点关注descriptor行（如(Ljava/lang/Object;)V） - 若发现你写的
set(Object)与编译器生成的桥接方法 descriptor 完全相同，就删掉或重命名该方法 - 典型场景：子类重写
<T> void set(T)后，编译器生成void set(Object)；此时再定义同签名的set(Object)就会报错
改用类型令牌（Class<T>）做运行时分发
当多个操作逻辑相似但目标类型不同，又必须统一入口时，放弃重载，改为接收类型证据：
立即学习“Java免费学习笔记（深入）”；
- 定义单一方法：
<T> T parse(String data, Class<T> type)，擦除后是Object parse(String, Class)，无冲突 - 内部用
type.cast()或Gson.fromJson(data, type)安全转换 - 适用于通用解析器、配置加载、跨模块数据适配等需要灵活支持多种目标类型的场景
重构接口职责，避免多泛型接口撞车
如果一个类同时实现 Processor<String> 和 Validator<Long>，而两者都有 handle(T)，擦除后全变成 handle(Object)，硬重载走不通。
- 按语义拆分方法：如
processString(String)和validateLong(Long) - 引入非泛型委托层：定义
Handler接口，内部持有具体类型处理器，并通过Class<T>或枚举标识类型意图 - 让各泛型接口的默认方法调用对应语义方法，而非挤在同一个方法名下
