Java方法重载与varargs匹配时，编译器严格按精确匹配→类型提升→装箱拆箱→varargs兜底顺序选择；禁止共存同名varargs与数组参数、仅返回值不同的重载，以及歧义性varargs组合。
Java 方法重载遇上可变长参数（varargs）时，编译器匹配逻辑看似简单，实则暗藏多处易踩的歧义陷阱。关键不是“能不能重载”，而是“编译器会不会选错”——一旦选错，轻则调用非预期方法，重则直接编译失败。
一、三类硬性冲突：写了就报错
以下组合在同一个类中**绝对不能共存**，JVM 编译器会直接拒绝：
-
可变参数方法 + 同类型数组参数方法
例如：
void log(String... msgs)和void log(String[] msgs)—— 编译器认为签名重复，不通过。 -
两个可变参数方法，仅靠参数个数区分
例如：
void print(String... s)和void print(String a, String b, String... s)—— 调用print("x", "y")时无法决定走哪个，报reference to print is ambiguous。 -
仅靠返回值不同重载
例如：
int sum(int...)和long sum(int...)—— Java 不支持，编译失败。
二、安全重载的关键：参数类型本质不同
真正能稳定共存的重载，必须让编译器一眼识别出“谁更贴切”。常见可行模式：
-
固定参数 vs 可变参数，且首参类型不同
void handle(int code, String... msg)和void handle(String tag, String... msg)—— 传handle(404, "not found")必定匹配第一个。 -
泛型擦除后签名可区分
void process(List和list) void process(String... items)—— JVM 中前者是List，后者是String[]，不冲突。 -
带明确类型前缀的可变参数
void update(String sql, Object... args)和void update(String sql, Object[] args, int[] types)—— 后者因含原始类型数组，签名唯一。
三、调用时的实际匹配顺序
编译器不是随机选，而是按严格优先级逐级筛选：
-
精确匹配：参数个数、类型完全一致（如传
"a"调用f(String)）； -
自动类型提升：如
byte→int、char→int； -
装箱/拆箱：如
int→Integer； -
可变参数兜底：只有前三步都失败，才考虑
...版本。
这意味着：哪怕你定义了 f(String...)，只要同时存在 f(String)，传一个字符串就永远走固定参数版，不会“降级”到 varargs。
四、Kotlin 调用 Java 时的特殊坑
当 Kotlin 调用含原始类型数组参数的 Java 方法（如 int[]），注意：
- Kotlin 的
Array对应 JVM 的Integer[]，不是int[]； - 若 Java 方法要求
int[]，必须用list.toIntArray()或intArrayOf()显式生成原始数组； - 否则 Kotlin 编译器可能跳过该重载，转而匹配
Object...版本，导致运行时类型错误或逻辑异常。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
