有效的方法重载需满足：①方法名相同；②参数列表不同（个数、类型或顺序）；③与返回类型、访问修饰符、异常声明无关。
Java 中没有“函数”，只有“方法”；所谓“方法重载”不是靠名字区分，而是靠 参数列表（类型、个数、顺序）的差异来实现编译期多态——只要 方法名 相同，参数列表 不同，就构成重载，与 返回类型 和 访问修饰符 无关。
什么是有效的方法重载？看这三条硬规则
重载判断只发生在编译阶段，JVM 不参与。以下情况才算真正重载：
-
参数个数不同：比如print(String s)和print(String s, int n) -
参数类型不同：比如process(int x)和process(double x)（注意：int和Integer算不同类型，但自动装箱可能引发歧义） -
参数顺序不同：比如build(String name, int id)和build(int id, String name)
以下写法 不构成重载：
- 仅
返回类型不同（如int getValue()和String getValue()）→ 编译报错：duplicate method - 仅
访问修饰符不同（如public void run()和private void run()）→ 同样报错 - 仅
异常声明不同（如throws IOExceptionvsthrows SQLException）→ 不影响重载判定
为什么 int 和 Integer 容易引发调用歧义？
当存在 method(int x) 和 method(Integer x) 时，传入字面量 5 会优先匹配 int 版本（基本类型优先于包装类）；但若传入 null，编译器无法确定该选哪个，直接报错：reference to method is ambiguous。
立即学习“Java免费学习笔记（深入）”；
常见踩坑场景：
- 使用
var声明变量后传参，如var a = 10;→ 实际类型是Integer，可能意外触发包装类版本 - 泛型方法 + 重载组合时，类型推导失败导致编译错误
- Android 开发中，View 的
setVisibility(int)和自定义setVisibility(Visibility)枚举方法共存，传0仍走int版本，容易误以为没生效
重载解析过程：编译器到底怎么选？
Java 编译器按三阶段尝试匹配（JLS §15.12.2）：
-
第一阶段：只考虑不发生自动装箱/拆箱、不发生可变参数（
...）的精确匹配 - 第二阶段：允许装箱/拆箱，但排除可变参数
- 第三阶段：允许可变参数（此时也允许装箱/拆箱）
这意味着：foo(String...) 是最“兜底”的重载，容易被意外选中。例如：
void foo(String s) { System.out.println("exact"); }
void foo(String... s) { System.out.println("varargs"); }
foo("a"); // 输出 "exact" —— 第一阶段已匹配成功
foo(); // 输出 "varargs"
foo(null); // 输出 "exact"（null 可赋给 String）
但如果删掉第一个方法，foo("a") 就会进入第三阶段，拆成 new String[]{"a"} 调用 varargs 版本。
实际开发中建议避开的重载模式
为降低维护成本和调用风险，这些重载组合应尽量避免：
-
void handle(List和) void handle(String...)→ 字符串数组字面量{"a","b"}会优先匹配后者，而非预期的 List 版本 -
void post(Object o)和void post(String s)→ 传null时编译失败，且post(new Object())和post("x")行为割裂，语义不清 - 在继承体系中对父类方法做“看似重载实为重写”的操作，例如子类加了个
draw(double scale)，而父类有draw(float scale)→ 外部调用者可能因精度隐式转换产生非预期行为
重载本身不是问题，问题在于它把决策压力转移到了编译器和调用者身上。一旦参数类型接近、存在隐式转换链或涉及 null，就很容易滑向不可控。
