Java方法签名到底指哪几块
Java方法签名不包含返回类型，只由方法名、参数类型（顺序和个数）共同构成。这是判断两个方法是否“重复”的唯一依据——编译器靠它报错 duplicate method，JVM靠它做重载解析和字节码分派。
常见误解是把返回类型或异常列表也算进去，但它们不影响签名。比如 int foo(String) 和 String foo(String) 在同一个类里能同时存在，编译通过；但 void foo(String) 和 void foo(int) 就不行，因为参数类型不同才构成有效重载。
为什么重载不能只靠返回类型区分
因为调用方在写代码时，不一定会接收返回值。JVM在生成字节码时，无法仅凭调用点上下文反推该选哪个版本。
- 编译期：调用
foo("x")时，如果只有返回类型不同，编译器无法确定目标方法，直接报错 - 运行期：字节码指令如
invokestatic必须明确指向一个签名，没有“根据返回值动态绑定”这回事 - 泛型擦除后更明显：
List<string> get()</string>和List<integer> get()</integer>擦除后都是List get()，若只靠返回类型区分，连编译都过不了
泛型方法和桥接方法怎么影响签名判断
泛型本身不参与签名，但编译器生成的桥接方法（bridge method）会暴露真实签名。这时候容易误以为“签名变了”，其实是编译器在补逻辑。
立即学习“Java免费学习笔记（深入）”；
比如：
class Box<T> {
T value;
void set(T t) { value = t; }
}
编译后会额外生成一个 void set(Object) 桥接方法，用来支持子类重写（如 Box<string></string> 被继承时）。这个桥接方法和原始 set(String) 的签名不同，但它不是你写的，也不该被手动调用。
- 自己写的泛型方法，签名中泛型参数全被擦除，例如
<t> T getId(T t)</t>签名实际是Object getId(Object) - 接口默认方法 + 泛型实现类可能触发更多桥接，导致
javap -s看到多个同名方法，别慌，那是编译器在干活 - 用
Method.getGenericSignature()可以拿到带泛型的字符串描述，但这不是 JVM 运行时用的签名
数组维度和包装类对签名的影响很实在
数组类型算独立类型，int[] 和 int[][] 是完全不同的参数类型；而基本类型和其包装类也互不兼容——这点在重载选择时特别容易踩坑。
-
void process(int)和void process(Integer)是两个独立签名，自动装箱不会让它们“合并” -
void handle(String...)编译后等价于void handle(String[])，所以不能和后者共存 -
void run(char)和void run(Character)同时存在时，传字面量'a'会优先匹配char版本；传new Character('a')才走包装类版 - 注意
byte、short、char作为参数时，整数字面量（如1）默认是int，不会自动缩小，除非显式强转
方法签名这事看着简单，但一旦混入泛型、数组、自动拆装箱、可变参数，就很容易在编译期无声掉坑里——尤其当 IDE 没标红、却在运行时报 NoSuchMethodError 的时候，大概率是签名层面的错位没被及时发现。
