方法重载必须满足：同一类中方法名相同、参数列表不同（类型/数量/顺序至少一者不同），返回值类型和访问修饰符不影响判定。
方法重载必须满足哪些条件？
Java 中的方法重载（Overloading）不是“随便改个参数就能成”，它有明确的编译期判定规则：同一个类中，多个方法名相同但 参数列表 不同（类型、数量、顺序至少一项不同），返回值类型和访问修饰符不影响重载判断。
常见错误现象：void print(String s) 和 String print(String s) 不能构成重载——仅返回值不同，编译报错 duplicate method；void print(int a, String b) 和 void print(String b, int a) 可以重载——参数顺序不同，属于不同签名。
- 参数类型不同优先于自动装箱/拆箱判断（如
intvsInteger，优先匹配基本类型） - 可变参数（
String...）是重载的“兜底选项”，只有在无更精确匹配时才被选中 - 泛型擦除后若签名重复（如
void handle(List<string>)</string>和void handle(List<integer>)</integer>），编译不通过
为什么重载不看返回值类型？
因为调用处无法仅凭方法名和参数推断该取哪个返回值。Java 编译器在解析方法调用时，只根据实参类型、个数、顺序查找最匹配的 方法签名，而返回值类型属于“调用后的结果”，不参与匹配过程。
举个例子：int getValue() 和 String getValue() 同时存在，当你写 getValue() 而不赋值或不参与表达式，编译器根本不知道你想调哪个——这会导致语义模糊，所以语言层面直接禁止。
立即学习“Java免费学习笔记（深入）”；
- 这和方法覆盖（Override）不同：覆盖允许返回协变类型（子类返回更具体的类型），但那是运行时多态，基于继承关系
- 如果真需要类似“按返回值区分”的行为，得靠显式命名（如
getIntValue()/getStringValue()）或工厂模式
重载与自动类型提升、装箱、varargs 的优先级怎么算？
当一个调用能匹配多个重载版本时，Java 按严格等级选择：精确匹配 > 自动类型提升（如 byte→int） > 装箱/拆箱 > 可变参数。这个顺序不可跳过，也不叠加。
例如有这三个方法：void f(int x)、void f(Integer x)、void f(int... x)，调用 f(5) 一定选第一个；调用 f(new Integer(5)) 选第二个；调用 f() 或 f(1,2) 才落到第三个。
- 注意
char、short、byte传入int参数的方法会被提升匹配，而不是报错 -
null实参可能引发歧义：若同时存在f(String)和f(Integer)，f(null)编译失败，提示 “reference to f is ambiguous” - varargs 总是最后考虑，哪怕你传了数组（
f(new int[]{1})会优先匹配f(int...)而非f(int[])，除非后者明确定义）
IDEA 或 javac 报 “cannot resolve method” 是重载问题吗？
不一定，但很可能是重载解析失败。典型场景包括：参数为 null 且多个引用类型重载共存；使用了 Lambda 但函数式接口未唯一匹配；泛型方法重载时类型推导失败。
调试建议：把实参换成具体字面量再试。比如原调用 process(obj) 报错，改成 process("hello") 或 process(42) 看是否正常——如果可以，说明问题出在 obj 的静态类型太宽泛或为 Object，编译器无法决定走哪个重载分支。
- 避免让重载方法接受过于宽泛的父类或接口（如全用
Object），容易导致调用端模棱两可 - 使用
@SafeVarargs不能解决重载歧义，它只抑制泛型可变参数的警告 - javac 9+ 对某些复杂重载（尤其是涉及 Lambda + 泛型推导）的错误提示更清晰，老版本可能只报 “no suitable method found”
Number 子类）、越依赖隐式转换，就越容易在某次新增重载后悄悄破坏原有调用逻辑。 
