方法重载匹配发生在编译期，依据编译时参数类型、数量和顺序确定调用版本，遵循三阶段规则：先精确匹配与基本类型提升，再装箱/拆箱，最后可变参数；null值易致歧义，泛型重载需避免擦除后签名冲突。
方法重载的匹配发生在编译期，不是运行时
Java 方法重载（overloading）的解析完全由编译器完成，和多态、virtual 或 override 无关。调用哪个重载版本，取决于**编译时已知的参数类型、数量和顺序**，而不是实际传入对象的运行时类型。
这意味着：
- 即使你传入一个子类实例，只要变量声明类型是父类，编译器就只考虑该父类视角下可匹配的重载方法
-
null值不提供类型信息，若多个重载都接受引用类型，编译会失败（ambiguous） - 自动拆箱/装箱、基本类型提升（如
int→long）属于合法的隐式转换，但不会跨类别（比如int不会转成Boolean）
参数匹配的三阶段规则（JLS §15.12.2）
Java 编译器按严格顺序尝试三轮匹配，一旦某轮找到至少一个适用方法，就不再进入下一轮：
-
第一阶段：只考虑不依赖自动装箱/拆箱、不依赖可变参数（
...）的精确匹配或基本类型提升（如byte→int） - 第二阶段：加入自动装箱/拆箱，仍排除可变参数
-
第三阶段：最后才考虑可变参数方法（
void foo(String...)）
例如：
立即学习“Java免费学习笔记（深入）”；
void m(Number n) {}
void m(int i) {}
void m(Integer i) {}
void m(Object o) {}
m(42); // 匹配 m(int i)，第一阶段即成功，不会选 m(Integer) 或 m(Number)
如果把 m(int i) 注释掉，m(42) 就会走第二阶段，匹配 m(Integer i)（int → Integer 装箱）。
常见歧义错误与避坑点
最典型的编译错误是 reference to XXX is ambiguous，通常由以下情况触发：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 两个重载方法参数类型处于同一继承层级，且都可通过隐式转换接收实参（如
foo(String)和foo(CharSequence)，传"abc"） - 同时存在基本类型和包装类型参数的方法，且实参是字面量（如
foo(int)和foo(Integer)，传5是 OK 的；但若还有foo(long)，foo(5)仍匹配int版本；而foo(null)就会歧义） - 可变参数方法和其他方法共存时，优先级最低，但若前两轮无匹配，它可能被选中——这常导致意料之外的行为
示例歧义：
void log(String s) {}
void log(StringBuilder sb) {}
log(null); // 编译错误：ambiguous
解决方式只能显式转型：log((String) null) 或 log((StringBuilder) null)。
泛型方法重载要格外小心
泛型方法本身不参与重载解析的“类型擦除后签名”比较。也就是说，<t> void f(T t)</t> 和 void f(Object o) 在擦除后都是 f(Object)，属于重复声明，编译直接报错。
更隐蔽的问题是：泛型方法和非泛型方法共存时，编译器优先选择“更具体”的非泛型版本（如果能匹配）：
void process(List<String> list) {}
<T> void process(List<T> list) {}
process(Arrays.asList("a", "b")); // 调用第一个，非泛型更具体
但如果传入 Arrays.<integer>asList(1, 2)</integer>，第一个方法就不匹配（类型不兼容），才会退到泛型版本。
真正容易出错的是泛型擦除后签名冲突 —— 比如 <t extends number> void g(T t)</t> 和 void g(Number n)，擦除后都是 g(Number)，非法重载。
