Java方法重载本质是编译期静态分派，由编译器根据方法名和参数类型列表（顺序、数量、类型）在编译阶段确定调用目标，返回值、throws、访问修饰符不参与区分。
Java方法重载的本质是编译期静态分派
Java里所谓“重载”，不是运行时决定调用哪个方法，而是编译器根据方法名 + 参数类型列表（顺序、数量、类型）在编译阶段就锁死目标方法。返回值类型、throws声明、访问修饰符都不参与区分。
常见错误现象：method() is already defined —— 这说明你试图仅靠返回值不同或仅throws不同来重载，编译直接报错，根本不会进入运行阶段。
- 参数类型必须是“可区分的”：比如
int和Integer在重载中算不同（但要注意自动装箱可能引发歧义） - 数组维度差异算不同：
foo(int[])和foo(int[][])可共存 - 泛型擦除后若签名相同，编译不通过：比如
bar(List<string>)</string>和bar(List<integer>)</integer>擦除后都是bar(List)，不能重载
调用时到底匹配哪个重载版本
调用methodName(arg1, arg2)时，JVM不查运行时类型，只看arg1、arg2的**编译时类型**，再按三步匹配：精确匹配 → 自动类型提升（如byte→int） → 自动装箱/拆箱/可变参数（优先级最低）。
容易踩的坑：null字面量没有类型，当多个重载都接受引用类型时，编译器会报错reference to xxx is ambiguous。
- 示例：
void process(String s)和void process(Object o)同时存在，调用process(null)会编译失败 - 解决办法：显式转型，比如
process((String) null)或process((Object) null) -
var变量声明会推导出具体类型，不影响重载决策；但Object o = "hello"这种写法会让o的编译时类型是Object，哪怕实际是String
可变参数（...）和重载的冲突风险
void foo(String... args)本质是接收一个String[]，但它在重载解析中属于“兜底选项”。只要存在更精确的匹配，就不会选它。
典型陷阱：当同时定义了foo(String s)和foo(String... args)，传入"a"会调用前者；但传入null时，如果只有这两个版本，会优先匹配foo(String...)（因为null可作String[]），而不是报错。
- 更危险的是：加了
foo(String[] arr)后，foo(null)就变成二义性调用，编译失败 - 性能影响：可变参数每次调用都会新建数组，高频场景慎用；且它无法和同名的
foo(String[])共存 - 建议：除非明确需要支持任意长度参数，否则优先用明确参数列表，避免引入歧义
继承体系下重载与重写的混用误区
子类里写一个和父类同名但参数不同的方法，是重载；写一个和父类签名完全一致的方法，是重写。这两者可以共存，但容易误判调用路径。
关键点：重载发生在同一个类或父子类的**编译时可见范围**内；而重写是运行时多态的基础。如果子类重载了一个新方法，父类引用指向子类实例时，**这个重载方法不可见**。
- 示例：父类有
void run()，子类加了void run(int speed)（重载）和@Override void run()（重写）。用Parent p = new Child()调用p.run(10)会编译失败——因为Parent类没声明该方法 - 想让重载对父类引用也生效？不行。这是设计意图问题，不是语法限制
- 调试时注意IDE提示：灰色方法名表示该重载只在子类作用域有效
重载的边界很清晰，但它的“静态性”和类型推导规则，恰恰是多数人调试时卡住的地方。尤其当涉及null、自动装箱、泛型、继承混合时，编译器的选择往往反直觉。别依赖运行时去试，先用javap -c看字节码里实际调用的是哪个符号。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
