Java泛型在运行时被擦除，导致无法仅凭类型参数重载方法；应通过语义化命名、委托模式或提取公共逻辑来规避冲突，并用javap验证字节码签名。
Java 中泛型是编译期特性，运行时不存在类型参数——这就是类型擦除。它直接导致一个关键限制：不能仅靠泛型类型参数来区分重载方法。理解这一点并主动规避冲突，是写出可编译、可维护泛型代码的基础。
类型擦除让“看起来不同”的方法变成“完全一样”
泛型方法或接口方法在编译后，所有类型参数都会被擦除：
-
<T> void handle(T item)→void handle(Object item) -
<U> void handle(U item)→void handle(Object item) -
void handle(List<String>)和void handle(List<Integer>)→ 都变成void handle(List item)
JVM 方法签名由方法名、参数类型（擦除后）、返回类型共同决定。只要这三者完全一致，就视为同一个方法。所以编译器会报错：method handle(List) is already defined
这不是逻辑错误，而是字节码层面的硬性约束。
立即学习“Java免费学习笔记（深入）”；
看真实签名，别信源码表象
光看 .java 文件容易误判。要用 javap -s 查看编译后的 descriptor：
javac MyHandler.java javap -s MyHandler
关注输出中类似这样的行：
descriptor: (Ljava/util/List;)V
如果两个方法的 descriptor 完全相同，它们就不可能共存。这是排查冲突最可靠的依据。
用语义命名代替泛型重载
不要写：
void process(List<String> list) { ... }
void process(List<Integer> list) { ... } // ❌ 编译失败改成：
void processStrings(List<String> list) { ... }
void processNumbers(List<Integer> list) { ... } // ✅ 清晰、安全、无冲突这样既避开擦除问题，又让调用意图一目了然。如果内部逻辑相似，可提取公共私有方法统一处理。
委托或抽象统一入口，而非强行实现多个接口
当一个类要同时实现 Processor<T> 和 Validator<U>，且二者都有 handle(T) 方法时，优先考虑：
- 这两个接口是否真代表不同职责？如果是，就用不同方法名（如
process()和validate()） - 如果职责高度重叠，不如定义一个更通用的接口，或让当前类只实现一个核心接口，另一个通过组合委托给内部对象完成
例如：
class MyHandler implements Processor<String> {
private final Validator<Integer> validator = new IntegerValidator();
@Override
public void handle(String s) { /* 处理字符串 */ }
public void validate(Integer i) {
validator.handle(i); // 委托，不暴露同名方法
}
}注意桥接方法带来的隐式冲突
继承泛型类时，编译器会自动生成桥接方法（bridge method）。比如子类覆写 setValue(Date)，父类原始方法是 setValue(Object)，编译器会生成一个 setValue(Object) 桥接方法。
如果你手动再写一个 setValue(Object)，就会和桥接方法冲突。用 javap -c -v 查看带 bridge 和 synthetic 标记的方法，确认是否有意外交叠。
不复杂但容易忽略
