Java方法重载是否成立取决于JVM字节码层面的方法签名，即方法名、参数类型列表（含泛型擦除后形式）的组合，返回类型、修饰符、参数名等均不参与；泛型擦除、基本类型与包装类、数组维度等细节易引发签名冲突。
Java 中方法重载（overload）能否成立，不取决于你“觉得”两个方法看起来不同，而完全由 JVM 在字节码层面识别的方法签名（method signature）决定。这个签名是 JVM 定位、分派和校验方法的唯一依据，不是编译器的“善意提醒”，而是运行时硬性规则。
方法签名到底包含什么
JVM 只认三样东西组合成的签名：
-
方法名（一字不差，大小写敏感，比如
main和mayne是两个世界） -
参数类型列表（按声明顺序，精确到每个类型的擦除后形式，如
int、java/lang/String、[Ljava/lang/List;） -
泛型擦除后的类型信息（编译期参与重载判定，但运行时不存在；
List<String>和List<Integer>擦除后都是List，签名相同）
以下统统不参与签名：返回类型、异常声明、public/static 等修饰符、参数名、可变参数语法（String... 编译后就是 String[]，签名等价）。
为什么仅靠返回类型无法重载
JVM 调用指令（如 invokestatic）在字节码里只记录符号引用：MethodName(ParamDesc)。括号里是参数描述符，括号外是方法名——返回类型编码虽在完整描述符中（如 (I)D 表示 int → double），但方法解析阶段只比对括号内部分。
- 写
int getValue()和String getValue()？编译直接报错：duplicate method getValue() in class X - 调用
getValue()时，JVM 不知道你要的是 int 还是 String——它连“调用点上下文有没有接收变量”都看不到，更别说推断返回意图 - 字节码验证器必须能在不执行代码的前提下，静态确认每个调用指向唯一目标。靠返回值？做不到
实战中高频踩坑的签名冲突场景
真正让开发者卡住的，往往不是概念，而是擦除、装箱、数组这些细节在签名层“悄悄打架”：
-
泛型擦除导致隐形冲突：
<T> void handle(List<T> list)和void handle(List list)擦除后都是(Ljava/util/List;)V，编译失败 -
基本类型 vs 包装类是两个签名：
void run(int)和void run(Integer)可共存，但传null会触发reference to run is ambiguous -
数组维度即类型：
void test(int)、void test(int[])、void test(int[][])是三个完全独立签名；传new int[]{1}一定进int[]版本 -
char 和 int 字面量的隐式转换边界：传
'a'优先匹配char参数；传97默认走int；传(char)97才强制进char版本
桥接方法：编译器帮你补的“签名空缺”
泛型类被继承或实现接口时，编译器会自动生成桥接方法（bridge method），它们有真实、合法的 JVM 签名，但源码里你看不见。
- 例如
class Box<T> { T get() { } }编译后会有Object get()（桥接）和具体化版本（如String get()） - 反射获取方法时会看到它，但它不可调用、不可重写、也不该出现在设计决策里
- 它的存在说明：签名唯一性校验发生在字节码层，连编译器生成的“影子方法”都要参与比对
