Java方法重载只看参数列表（个数、类型、顺序），返回类型、修饰符、throws等均无关；需避免varargs与固定参数冲突、泛型擦除导致的歧义，以及重载与重写的混淆。
Java 中方法重载（Overloading）不是“能不能做”，而是“怎么写才被编译器认作不同方法”——关键不在名字，而在 参数列表 的结构是否可区分。
方法重载只看参数列表，返回类型无关
编译器判断两个方法是否构成重载，**完全忽略返回类型**。哪怕 int add(int a, int b) 和 String add(int a, int b) 同时存在，编译直接报错：duplicate method add(int, int)。
- 必须改变：参数个数、参数类型、参数顺序（如
(int, String)vs(String, int)） - 不能仅靠：返回类型不同、访问修饰符不同、
throws声明不同 - 注意：自动拆箱/装箱可能引发意外匹配，比如
void foo(Integer i)和void foo(int i)不能共存（调用foo(5)时编译器无法确定选哪个）
常见错误：重载与重写的混淆
重载发生在同一个类中，是编译期行为；重写（Override）是子类改写父类方法，是运行期行为。二者规则互不干扰，但容易因命名习惯误踩坑：
-
@Override注解只能用于重写，加在重载方法上会编译报错：method does not override or implement a method from a supertype - 若父类有
void print(Object o)，子类定义void print(String s)——这是重载，不是重写，@Override不合法 - 重载方法之间无继承关系，JVM 不参与分派；重写才涉及动态绑定和多态
可变参数（varargs）的重载陷阱
void log(String... msgs) 看似灵活，但和 void log(String msg) 共存时，编译器优先选择更具体的匹配，即单个 String 参数版本。但以下组合会出问题：
立即学习“Java免费学习笔记（深入）”；
void handle(int... nums) void handle(int n, int... rest)
调用 handle(1) 时编译失败：reference to handle is ambiguous，因为两个方法都可接受单个 int 参数。
- varargs 必须是参数列表最后一个元素
- 避免让 varargs 方法与“相同前缀 + 更少固定参数”的方法共存
- 必要时用明确类型（如
List<Integer>）替代 varargs，提升可读性和可重载性
泛型方法重载的特殊限制
Java 泛型是类型擦除实现，所以 <T> void process(T t) 和 <T> void process(List<T> list) 可以重载，但 <T> void process(T t) 和 void process(String s) 就不行——擦除后都是 process(Object) 和 process(String)，看似不同，实则第一个泛型方法擦除后变成 process(Object)，而 String 是 Object 子类，调用 process("hi") 时编译器可能选错，甚至报错。
- 泛型方法的重载安全边界：依赖参数类型是否在擦除后仍可区分
- 推荐做法：优先用具体类型方法覆盖常见场景，泛型方法作为兜底，而非并列重载
- IDE（如 IntelliJ）常标黄提示 “Unchecked generic call”，这往往是重载歧义的前兆
重载真正的复杂点不在语法，而在调用时的解析逻辑——编译器要从所有候选方法中选出最具体的那个，而这个过程受自动类型转换、装箱拆箱、varargs 展开、泛型擦除共同影响。写的时候看着没问题，一调用就报错或走错分支，往往是因为没把参数类型的“实际可匹配路径”想全。
