Java方法重载只看参数列表，与返回值无关；判定标准是同名方法的参数个数、类型或顺序不同，编译期静态绑定，不涉及运行时多态。
Java 方法重载只看参数列表，和返回值无关
方法重载的判定标准非常明确：同一个类中，方法名相同但 参数列表 不同（参数个数、类型或顺序不同），就构成重载。返回值类型不同不算重载——编译器根本不看它。
常见错误现象：void print(String s) 和 String print(String s) 无法共存，编译报错 duplicate method print(String)。JVM 在调用时只靠参数签名找方法，返回值不参与匹配。
- 参数类型不同才算：比如
add(int, int)和add(double, double) - 参数个数不同也算：比如
log(String)和log(String, Object) - 参数顺序不同也算：比如
build(String, int)和build(int, String)（但慎用，可读性差） - 仅修饰符（
public/private）、异常声明（throws）、返回值变化，都不触发重载
重载解析发生在编译期，不是运行时多态
重载是静态绑定，编译器根据你写的实参类型、个数、字面量形式，直接决定调用哪个方法。它和 override（重写）有本质区别：重写才是运行时多态，依赖对象实际类型。
使用场景：写工具类时提供多种便捷入口，比如 StringUtils.isEmpty() 有 String、CharSequence、Object 三个重载，但调用哪一个是编译时就锁死的。
立即学习“Java免费学习笔记（深入）”；
- 如果传的是
null，且多个重载都接受引用类型，编译可能失败（歧义），例如foo(Object)和foo(String)同时存在时调用foo(null)会报错 - 自动拆箱/装箱会影响重载选择，比如
int实参会优先匹配method(int)而非method(Integer)，哪怕后者是精确引用类型 - 子类继承父类重载方法时，不会“合并”父类和子类的同名方法集；子类新增重载只作用于子类实例的直接调用
泛型方法和重载容易互相干扰
泛型方法的类型擦除发生在编译后，但重载解析在擦除前完成。这意味着两个泛型方法如果擦除后签名相同，编译就过不去，哪怕它们的类型参数不同。
典型错误：<T> void handle(T t) 和 <U> void handle(U u) 不能共存——擦除后都是 handle(Object)，编译器视为重复定义。
- 泛型方法和普通方法可以重载，例如
handle(String)和<T> handle(T)是合法的 - 但
<T extends Number> handle(T)和<T extends Comparable> handle(T)依然冲突，因为擦除后都是handle(Object) - 如果想实现类似效果，改用不同方法名，或用
Object+ 运行时instanceof分发（虽然失去编译检查）
重载对性能没影响，但对可维护性有隐性成本
编译期决定调用哪个方法，生成的字节码里就是具体的方法符号引用，运行时没有额外开销。但人阅读和维护时容易混淆。
容易踩的坑：过度重载导致 API 表面灵活，实则调用行为难以预测。比如一个 parse() 方法有 7 个重载，传 "" 或 null 时到底走哪个，得翻源码甚至反编译才能确认。
- 优先用明确的方法名替代重载，例如
parseJson()/parseXml()比parse(String)+ 类型推断更清晰 - 如果必须重载，把参数差异拉得足够开（比如一个收
String，一个收Path），避免靠细微类型转换区分 - IDE 的 “Go to Declaration” 在重载多时可能弹出多个选项，这时候你得自己判断哪个是实际执行的——它取决于你写调用时的实参上下文，不是当前光标位置
最麻烦的不是写重载，是别人调用你写的重载时，发现行为和预期不一致，而问题藏在编译期类型推导里，不报错、不抛异常、只默默走错分支。
