Java重载方法的区分核心依据是方法签名，即方法名加参数类型有序列表；返回类型、异常声明、修饰符不参与签名，无法用于重载区分。
Java中重载方法的区分，**核心依据是方法签名（Method Signature）**，即方法名 + 参数类型列表（按声明顺序），与返回类型、异常声明、修饰符无关。
方法签名到底包含什么
根据Java语言规范（JLS §8.4.2），方法签名由以下两部分组成：
- 方法名称
-
参数类型的有序列表（注意：是类型本身，不是参数名；且顺序敏感，
void foo(int, String)和void foo(String, int)是不同签名）
以下内容不参与签名构成，因此不能用于区分重载：
– 返回类型（int get() 和 String get() 不能共存）
– 异常声明（void run() throws IOException 和 void run() throws Exception）
– 访问修饰符（public/private）、static、final 等
编译期如何匹配重载方法
Java编译器在调用处（如 obj.doX(1, "a")）执行静态解析（Static Resolution），分三步完成匹配：
-
第一步：筛选可见方法 —— 只考虑当前作用域可访问（如非
private、符合包/继承可见性）且方法名匹配的候选方法 -
第二步：寻找最具体匹配（Most Specific Match） —— 按参数实参类型，逐个比对形参类型是否可赋值（遵循 widening conversion 规则）。例如传入
short，void m(int)比void m(long)更具体；传入String，void m(CharSequence)和void m(Object)都可行，但CharSequence是更具体的父类型，优先选它（若二者无继承关系则报错） - 第三步：唯一性检查 —— 若存在多个“同样具体”的候选（如两个独立接口的实现方法、或两个无继承关系的类作为参数类型），编译失败，提示 “reference to X is ambiguous”
容易踩坑的典型场景
以下情况看似合理，实则会导致编译错误或行为不符合直觉：
-
自动装箱 + 重载：
void f(int)和void f(Integer)同时存在时，调用f(null)编译失败（ambiguous）；而f(5)会绑定到int版本（优先使用基本类型转换而非装箱） -
可变参数（varargs）的模糊性：
void g(String...)和void g(String)共存时，g("a")绑定到String版本（varargs 是最低优先级匹配）；但g((String)null)仍明确调用单参版本 -
泛型擦除不影响重载：由于类型擦除，
void h(T) void h(U)擦除后都是h(Object)，无法共存，编译报错
调试重载问题的小技巧
当遇到 “cannot resolve
- 用 IDE（如 IntelliJ）按住 Ctrl 点击方法调用，查看实际解析到哪个重载（显示灰色提示）
- 显式强转实参来引导匹配，例如
obj.process((Object)list)或obj.process((List>)null) - 避免过度依赖自动类型推断，尤其在涉及
null、泛型、基础类型与包装类混用时，优先使用明确类型的方法命名（如processAsList()/processAsString()）
