Java方法重载的参数匹配是编译期静态分派，依据声明类型和最具体方法原则：先筛选合法候选，再按参数类型继承关系选最具体者，无法唯一确定则报错。
Java 方法重载的参数匹配不是“模糊查找”，而是严格遵循编译期静态类型 + 最具体方法（Most Specific Method）规则。它不看运行时对象实际类型，只看变量声明类型和参数签名之间的兼容性与 specificity 关系。
编译器怎么挑出最精确的那个方法
当调用一个重载方法时，Java 编译器会按三步走：
第一步：筛选所有可调用的方法
找出所有参数个数相同、且每个实参类型能通过合法转换（包括恒等转换、扩展转换、装箱/拆箱、向上转型）匹配形参的方法。-
第二步：在候选集中找“最具体”的那个
如果只剩一个候选，直接选；如果有多个，就比谁更“具体”：- 若方法 A 的每个参数类型都能赋值给方法 B 对应位置的参数类型（即 A 的参数是 B 参数的子类型），则 B 更宽泛，A 更具体；
- 例如
String是Object的子类，所以m(String)比m(Object)更具体； - 同样，
Integer比Number具体，Number比Object具体。
第三步：无法唯一确定就报错
如果两个方法互不为对方的子类型（如m(String)和m(Integer)），又都接受当前实参（比如传null），编译器无法判断哪个更具体 → 报reference to xxx is ambiguous。
常见导致“不精确”的陷阱和应对
null 字面量没有类型，全靠推断
foo(null)时，若同时存在foo(String)和foo(Integer)，两者都“可接受 null”，但互不兼容 → 编译失败。
✅ 解法：显式转型，如foo((String) null)或统一用foo(Object)再做instanceof判断。继承关系太近，容易误判“最具体”
比如同时定义handle(CharSequence)和handle(StringBuilder)，传new StringBuffer()会失败——它实现CharSequence，但不是StringBuilder，也不继承它，两个都不完全匹配。
✅ 解法：避免混用有共同父接口但无直接继承关系的类型；或只保留一个足够宽泛的入口（如handle(CharSequence)），内部再区分。基本类型和包装类共存引发装箱歧义
process(int)和process(Integer)同时存在时，传字面量5会选前者；传Integer.valueOf(5)会选后者；但方法引用this::process在泛型上下文中可能无法推导 → 报错。
✅ 解法：同一语义只保留一种，优先用基本类型（性能好），或统一用包装类（便于 null 处理）。可变参数（varargs）抢跑固定参数版本
如log(String, Object...)和log(String, int[])并存，Kotlin 或某些场景下log("x", new int[]{1})可能被当成 varargs 调用。
✅ 解法：避免让 varargs 版本和数组版本参数类型交叉；必要时改名，或强制用int[]显式构造。
实际写法建议：让匹配变得清晰可控
- 用无继承关系的类型划清边界：比如
save(File)和save(String path)比save(String)和save(CharSequence)更安全； -
避免对同一语义设计多个引用类型重载，尤其含
null场景； - 对外暴露的 API 尽量减少重载层数，优先用 builder 模式或参数对象替代；
- 需要动态分派逻辑（如根据实际类型做不同处理），应改用重写（override）+ 多态，而非依赖重载。
匹配本身不复杂，但容易忽略类型兼容性的隐含路径。关键不是让编译器“猜”，而是提前把路铺直。
