Java重载解析优先选择更具体的方法，varargs仅在前三阶段无匹配时启用；String[]与String...共存时，类型精确匹配的String[]方法优先，泛型varargs与Object[]重载会导致编译歧义。
Java 中可变参数（varargs）方法在重载时，编译器会优先选择**更具体、更精确匹配**的重载版本；当存在与 varargs 形式签名高度相似的数组参数方法时，容易因“类型擦除”和“重载解析规则”引发意料之外的调用结果——甚至编译失败。
重载解析的基本优先级规则
Java 编译器对重载方法的选择分三阶段（JLS §15.12.2），关键点如下：
- 第一阶段：仅考虑不涉及自动装箱/拆箱、不使用 varargs 的方法（即“严格匹配”）。若找到唯一适用方法，则直接选用。
-
第二阶段：允许基本类型转换（如
int → long）、装箱/拆箱，但仍排除 varargs。 -
第三阶段：最后才考虑 varargs 方法（包括数组参数形式的 varargs 和显式声明为
T...的方法）。
这意味着：一个接受 String[] 的普通方法，比 String... 的 varargs 方法“更具体”，在参数能完全匹配时会被优先选中。
典型冲突案例：String[] 与 String... 同时存在
看这段代码：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
void print(String... args) { System.out.println("varargs"); }
void print(String[] args) { System.out.println("array"); }
<p>print("a", "b"); // 输出：varargs（匹配 String...）
print(new String[]{"x", "y"}); // 输出：array（精确匹配 String[]）
print(); // 输出：varargs（空 varargs 合法）</p>看似合理。但问题出现在以下调用：
String[] arr = {"p", "q"};
print(arr); // 输出：array —— 不是 varargs！
因为 arr 是 String[] 类型，与 print(String[]) 精确匹配，跳过 varargs 阶段。此时 print(String...) 虽然语法上也“能接住”（因为 String[] 可作为 varargs 的实参），但**它不是最具体的匹配项**，被忽略。
更隐蔽的编译错误：泛型 + varargs + 数组重载
下面代码无法通过编译：
<T> void method(T... args) { }
void method(Object[] args) { }
<p>method("a", "b"); // ❌ 编译错误：ambiguous reference</p>原因：
- method("a", "b") 中，两个方法都满足第三阶段（都支持 varargs 或数组语义）；
- 泛型 varargs <T> method(T...) 擦除后实际签名为 method(Object...)；
- 而 method(Object[]) 在重载解析第三阶段中，与 Object... “同样具体”（JLS 认为二者不可区分）；
- 编译器拒绝歧义，报错 reference to method is ambiguous。
规避建议与实践准则
-
避免同时声明
T[]和T...：尤其在公共 API 中，这是最直接的冲突源。 -
用不同方法名代替重载：例如
printAll(...)和printArray(...)，语义清晰且无歧义。 -
必要时加
@SafeVarargs并明确文档说明：提醒调用者该方法设计为 varargs 主路径，数组传入属于兼容性支持而非首选。 -
测试边界调用：特别是空参
method()、单数组method(arr)、多字面量method("x","y")，确认行为符合预期。
