java编译器在方法重载中依据静态类型和继承关系，在编译期选出最具体（most specific）的匹配方法；匹配分三阶段，优先纯静态类型，再装箱/拆箱，最后varargs；设计时应避免类型交叉兼容以消除歧义。
Java 编译器在方法重载中选择“最精确匹配”的方法，不是靠运行时类型或猜测，而是依据静态类型 + 类型继承关系 + 匹配阶段规则，在编译期就确定唯一目标。关键不在于“怎么让编译器选对”，而在于设计时就让候选方法之间有清晰的类型层级边界，避免模糊。
最具体类型优先：子类比父类更精确
当多个重载方法参数都能接受同一个实参（尤其是 `null` 或多态对象）时，编译器会从所有可匹配的方法中，选出参数类型**最具体（most specific）** 的那个。例如：
void handle(Object o) { System.out.println("Object"); }
void handle(String s) { System.out.println("String"); }
void handle(Integer i) { System.out.println("Integer"); }
调用 handle(null) 时：
-
null可匹配所有三个签名（因为所有引用类型都可为null） - 但
String和Integer都是Object的子类，所以Object被排除 - 而
String与Integer互不继承、不可转换 → 编译失败，报 ambiguous reference
若只保留 handle(Object) 和 handle(String)，则 handle(null) 会选 String 版本 —— 因为它比 Object 更具体。
匹配分三阶段：避免自动装箱和 varargs 干扰
Java 编译器按严格顺序尝试匹配，只在前一阶段无解时才进入下一阶段：-
阶段1（纯静态类型）：只考虑实参声明类型与形参类型的直接赋值关系（如
String→String，int→int），不涉及装箱、拆箱、向上转型 -
阶段2（允许装箱/拆箱）：如
int实参可匹配Integer形参，但int不能匹配Long（宽化+装箱不被支持） - 阶段3（允许 varargs）：仅当前两阶段都无匹配时启用，且 varargs 版本永远是兜底选项
这意味着：print(int) 和 print(Integer...) 同时存在时，传 5 一定走前者；传 new Integer[]{1,2} 才可能触发后者。
让类型边界不可交叉：主动切断隐式兼容链
歧义大多源于类型间存在隐式转换路径（继承、实现、基本类型宽化、装箱）。要确保“最精确”可判定，就得让候选参数类型彼此**互不兼容**：- 避免同时提供
handle(String)和handle(CharSequence)—— 因为StringBuilder是CharSequence但不是String，传入时两者都不完全匹配 - 用领域语义隔离类型：比如
handle(File)和handle(URI)，它们没有继承关系，也不会因null或泛型推导冲突 - 基本类型与包装类不混用：保留
process(int)或process(Integer)之一即可；二者共存时，process(42)选前者，process(Integer.valueOf(42))选后者，但方法引用this::process在泛型上下文中极易失败
反射调用必须显式指定类型数组
运行时无法依赖“最精确匹配”逻辑，反射不执行任何类型推导：- Java 中必须用
getDeclaredMethod("name", String.class)或getMethod("name", int.class, boolean.class) -
int.class≠Integer.class；String.class≠Object.class；子类实例传给父类参数，仍需按实际传参类型（如String.class）查找 - 调用
invoke时，实参类型也必须严格一致：传42给期望Integer的方法会抛异常，应传Integer.valueOf(42)
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
