java方法签名仅含方法名和参数列表（类型、数量、顺序），不含返回类型、异常、修饰符；是重载唯一依据，泛型擦除、装箱、桥接方法易引发隐性冲突。
Java方法签名到底包含哪些部分
方法签名只包括方法名和参数列表（参数类型、数量、顺序），不包括返回类型、异常声明、访问修饰符。这是重载判断的唯一依据，也是很多人误以为“返回类型不同就能重载”的根源。
常见错误现象：void print(String s) 和 String print(String s) 不能共存于同一类中，编译直接报错 duplicate method print(String) —— 因为签名完全相同。
- 参数类型必须精确匹配：
int和Integer是不同签名（基本类型 vs 包装类） - 可变参数
String...的签名等价于String[]，所以f(String...)和f(String[])冲突 - 泛型擦除后若签名相同，也视为重复：
get(List<string>)</string>和get(List<integer>)</integer>擦除后都是get(List)，无法重载
为什么重载不看返回类型
因为调用时 JVM 只根据变量声明、表达式上下文或显式强制转换来决定传参，但不会靠“我打算接什么返回值”去反推该调哪个方法。这会导致语义模糊和编译器无法静态确定目标方法。
使用场景：你写 add(1, 2)，JVM 必须在编译期就锁定调用的是 int add(int, int) 还是 double add(int, int) —— 但它没法从 int result = add(1, 2) 或 double d = add(1, 2) 反推，因为赋值发生在调用之后。
立即学习“Java免费学习笔记（深入）”；
- 如果允许按返回类型区分，
add(1, 2)单独一行（无赋值）就无法解析 - lambda 或方法引用场景更明显：
Function<integer string> f = MyClass::toString</integer>—— 这里toString()有多个重载，但编译器只看参数（无参），不看返回值
容易被忽略的泛型与桥接方法影响
泛型类继承或实现时，编译器会生成桥接方法（bridge methods），它们可能意外覆盖你写的重载逻辑。
例如定义 class Box<t> { void set(T t) {} }</t>，子类 StringBox extends Box<string></string> 中写 void set(String s)，表面看是重载，实际编译后会生成一个桥接方法 void set(Object o)，和父类签名一致，导致你的 set(String) 反而变成重写（override），不是重载（overload）。
- 用
javap -c StringBox能看到桥接方法，它是编译器加的，你代码里没写 - 这种情况下，
new StringBox().set("a")调用的是set(String)，但Box> b = new StringBox(); b.set("a")实际走的是桥接的set(Object) - 真正想重载，得避开泛型擦除后的签名冲突，比如加个额外参数：
void set(String s, boolean force)
重载解析失败时的真实报错特征
编译器报错不是笼统说“找不到方法”，而是分三类明确提示：
第一种是根本没匹配：no suitable method found for doWork(int, int)；第二种是模棱两可：reference to doWork is ambiguous，比如同时存在 doWork(int, Object) 和 doWork(Object, int)，而你传了 doWork(1, 1)；第三种是类型擦除冲突：method doWork(List<string>) is already defined in class X</string>。
- 注意
ambiguous错误往往出现在自动装箱/拆箱 + 可变参数混合时，比如foo(int...)和foo(Integer)同时存在，调用foo(1)就会歧义 - IDE 的提示有时比命令行编译器更“宽容”，别全信——以
javac实际输出为准 - 用
-Xlint:overloads编译参数能提前发现潜在的重载陷阱，比如无意中覆盖了父类方法却自以为是重载
最麻烦的从来不是语法记不住，而是泛型擦除、自动装箱、桥接方法这三者叠在一起时，签名看起来没冲突，运行时行为却和预期不一致。这时候别猜，先 javap 看字节码。
