Java泛型与重载/重写冲突根源在于类型擦除导致签名重复，必须避免用泛型参数区分重载或干扰重写；应改用语义化方法名、Class参数分发或委托机制解决。
Java 中方法重载与重写结合泛型时，冲突根源不在“怎么用”，而在于“不该这么用”——泛型类型参数本身不能作为重载区分依据，也不能在重写中依赖其运行时存在。擦除后签名重复是编译期硬约束，不是编码技巧能绕过的。关键是要放弃用泛型参数驱动重载或重写的思路，转而依靠语义、结构和显式类型信息来组织代码。
别让泛型参与重载决策
泛型方法如 <t> void handle(List<t>)</t></t> 和 <u> void handle(List<u>)</u></u> 擦除后都是 handle(List)，JVM 视为同一签名，直接报错。这不是写法问题，而是设计误用。
- 避免仅靠泛型实参不同定义多个同名方法，比如
process(List<string>)</string>和process(List<integer>)</integer> - 若处理对象语义不同，就用不同方法名：
processNames(List<string>)</string>、processIds(List<integer>)</integer> - 若逻辑高度一致，提取私有通用方法（如
private void doProcess(List> list)），对外暴露职责清晰的入口
重写泛型类方法时警惕桥接方法干扰
子类重写父类泛型方法时，编译器会自动生成桥接方法维持多态。若你手动写了擦除后签名相同的公开方法，就会和桥接方法冲突。
- 用
javap -c -v YourClass查看是否有带bridge和synthetic标记的方法 - 比对这些桥接方法的 descriptor（如
(Ljava/lang/Object;)V）是否和你写的某个方法重复 - 如有重复，删掉手动方法，或改名/改参，让桥接机制正常工作
用 Class 参数替代泛型重载逻辑
当确实需要按不同类型做差异化处理时，把类型信息从“编译期泛型”移到“运行时参数”上，既安全又可控。
立即学习“Java免费学习笔记（深入）”；
- 定义单一泛型方法：
<t> T getValue(Class<t> type)</t></t> - 调用时显式传入
String.class或Integer.class - 内部用
type.isInstance(obj)和type.cast(obj)做安全分发 - 该方式不依赖重载，无擦除冲突，类型检查仍在编译期保障
实现多个泛型接口时统一处理入口
例如同时实现 Processor<string></string> 和 Validator<long></long>，二者都有 handle(T)，擦除后都变成 handle(Object)，无法共存。
- 不要试图在同一个类里写两个
handle方法覆盖不同接口 - 改为语义化实现：
processString(String s)和validateLong(Long l)，再分别在@Override中调用 - 或采用委托：定义一个
HandlerDispatcher，接收Class>和实际处理器，运行时分发
