Java方法签名仅含方法名、参数类型列表（按序）、类型擦除后的泛型信息；不包括返回类型、异常、修饰符；是JVM识别方法及重载判定的唯一依据。
Java方法签名到底包含哪些内容
方法签名不包括返回类型、异常声明、修饰符（public/static等），只由三部分组成：方法名 + 参数类型列表（按声明顺序）+ 类型擦除后的泛型信息（仅限编译期参与重载判定）。这是JVM层面识别“同一个方法”的依据，也是重载（overload）能否成立的底线。
比如 void foo(String s) 和 int foo(String s) 在JVM里是同一个签名，不能共存；而 void foo(String s) 和 void foo(Object o) 是不同签名，可以重载。
-
String和Object是不同参数类型 → 签名不同 -
List<String>和List<Integer>擦除后都是List→ 签名相同（编译报错） -
void bar(int... nums)和void bar(int[] nums)擦除后都是int[]→ 签名相同（无法重载）
为什么返回类型不算进方法签名
JVM调用指令（如 invokevirtual）依赖符号引用中的方法名和描述符（descriptor），而描述符格式是 (参数类型编码)返回类型编码。但方法解析阶段只比对括号内部分；返回类型只影响调用方如何处理栈顶值，不参与目标方法定位。
也就是说：你写 String getValue() 和 Integer getValue()，编译器直接拒绝——不是因为语义冲突，而是因为生成的字节码里根本没法区分这两个方法。
立即学习“Java免费学习笔记（深入）”；
- 反例：
javac报错method getValue() is already defined in class X - 真实场景：想靠返回类型做API多态？必须改方法名，比如
getStringValue()/getIntValue() - 注意：桥接方法（bridge method）是编译器自动生成的，它有独立签名，但开发者不可见也不可控
泛型擦除怎么影响签名唯一性
泛型在运行时不存在，所有 <T>、<E> 全部被替换成其上界（通常是 Object）。所以带泛型的方法签名，实际只看擦除后的参数类型。
这导致两个常见陷阱：
-
<T> void process(List<T> list)和void process(List list)擦除后都是(Ljava/util/List;)V→ 编译失败 -
<T extends Number> void handle(T t)擦除为(Ljava/lang/Number;)V，和void handle(Number n)冲突 - 接口默认方法如果和父类方法签名擦除后一致，也会触发编译错误，不是覆盖也不是重载
什么时候会意外触发签名冲突
最隐蔽的情况发生在继承链中：子类重写父类方法时，如果泛型参数擦除后和父类方法一致，但又没加 @Override，编译器可能误判为新方法，结果报重复签名错误。
另一个高频坑是使用Lombok的 @Data 或 @Builder：它自动生成的 toString()、build() 等方法，若你手动写了同名方法且参数擦除后一致，就会冲突。
- 检查点：用
javap -s看字节码里的方法描述符，比对括号内是否完全一致 - IDE提示 “Duplicate method” 时，别急着删代码，先确认是不是擦除导致的假冲突
- Android开发尤其要注意：D8/R8对签名冲突更敏感，有时连Lambda生成的合成方法都会撞上
