Java方法签名仅含方法名和参数类型列表，不含返回值、异常、修饰符及参数名；泛型擦除、自动拆箱、基本类型与包装类等细节易引发重载歧义。
方法签名到底包含哪些部分
Java里方法签名只包括方法名和参数类型列表，不包含返回值类型、异常声明、访问修饰符，也不看参数名。这是很多人误以为改了返回值就能重载的根本原因。
-
void print(String s)和String print(String s)在同一个类里直接编译报错：duplicate method print(java.lang.String) - 参数类型顺序不同算不同签名：
process(int, String)和process(String, int)可共存 - 泛型擦除后若签名相同，编译也拒绝：
getList()（返回List<string></string>）和getList()（返回List<integer></integer>）无法共存
为什么重载不看返回值类型
因为调用处无法仅凭方法名和参数推断该取哪个返回值——JVM在字节码层面靠签名定位方法，而调用指令（如 invokestatic）不携带返回值信息。如果允许仅靠返回值区分，编译器就无法在调用点确定该跳转到哪个符号引用。
- 写
int x = foo();时，编译器必须静态决定调用哪个foo，但返回值是结果而非输入条件 - 这个设计保证了字节码验证阶段能明确解析每个方法调用的目标
- 想靠返回值做逻辑分支？得用显式类型转换或中间变量，不能依赖重载
容易被忽略的参数类型细节
自动拆箱、可变参数、数组维度、基本类型与包装类混用，都会让“看起来一样”的参数列表实际签名不同。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
test(int...)和test(int[])签名不同，但调用test(new int[]{1})会优先匹配后者 -
test(Integer)和test(int)是两个签名；传null时若两者都存在，编译直接报错：reference to test is ambiguous -
test(char)和test(int)：传字面量'a'会走char版本；传97走int版本；但传(char)97还是进char版本
泛型方法与桥接方法带来的签名干扰
泛型类中定义的方法，编译后可能生成桥接方法（bridge method），它们有独立签名，但对开发者透明。这会导致反射或字节码分析时看到“多出来”的方法。
- 类
class Box<t> { T get() { ... } }</t>编译后会有Object get()（桥接）和String get()（具体化后）两个签名 - 用
Class.getDeclaredMethods()遍历时会拿到桥接方法，但源码里根本没写它 - 判断是否重载冲突时，JVM按真实签名比对，桥接方法参与校验——所以泛型类里加新方法要小心隐式签名重复
事情说清了就结束。真正卡住人的往往不是概念，而是 null 传给重载方法时的歧义、int 和 Integer 的静默转换边界、还有泛型擦除后桥接方法悄悄占掉一个签名位置。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
