java编译器在方法重载中严格依据静态类型和继承关系，在编译期选出最具体的匹配方法；分三阶段：纯静态类型→装箱/拆箱/向上转型→varargs兜底，不依赖运行时类型。
Java 编译器在调用重载方法时，并不靠猜测或运行时类型，而是严格按静态类型和类型继承关系，在编译期就确定唯一匹配的方法。整个过程不是“找差不多的”，而是“选最具体的”。
匹配依据是声明类型，不是实际对象类型
比如 Object obj = new String("hello");，调用 print(obj) 时，编译器只看 obj 的声明类型 Object，不会因为实际是 String 就自动选 print(String)。只有传 new String("hello") 字面量或 String 类型变量时，才会考虑 String 版本。
三阶段匹配顺序不可跳过
编译器按固定优先级尝试匹配，前一阶段有解就不会进下一阶段：
- 第一阶段：纯静态类型直接兼容（如
int→int、String→String），不触发任何转换 - 第二阶段：允许装箱、拆箱、向上转型（如
int→Integer、String→Object） - 第三阶段：仅当以上都失败时，才考虑可变参数（varargs），且它永远是兜底选项
例如同时存在 log(String, int) 和 log(String, int...)，传 log("a", 5) 一定走前者；只有传 log("a", 1, 2, 3) 才触发后者。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
“最具体”由参数类型的继承关系决定
多个方法都能接受当前实参时（尤其是 null 或多态引用），编译器会选出参数类型最靠下的那个：
-
String比Object具体，因为String是Object的子类 -
ArrayList比List具体，因为ArrayList实现List - 但
String和Integer互不继承，无法比较谁更具体 → 此时调用handle(null)会报错：reference to handle is ambiguous
避免歧义的设计建议
- 不要同时提供
handle(String)和handle(CharSequence)：StringBuilder是后者但不是前者，容易卡在中间 - 基本类型和包装类别共存：
process(int)和process(Integer)同时存在时，字面量5走前者，Integer.valueOf(5)走后者，但泛型推导可能失败 -
null实参必须显式转型：foo((String) null)或改用统一入口foo(Object)再做instanceof分支处理
本质上，匹配不是“模糊查找”，而是类型系统在编译期的一次精准裁决。设计重载方法时，关键不是让编译器“理解你想要什么”，而是让参数类型之间有清晰、单向的继承或实现路径。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
