Java可变参数（Varargs）必须是方法参数列表中最后一个参数，且一个方法最多只能有一个；声明为Type... name，实为数组语法糖，编译后等价于Type[] name。
Varargs 的基本写法和语法限制
Java 中的变长参数必须是方法的最后一个参数，且一个方法只能有一个 varargs 参数。它本质是编译器把传入的多个实参自动包装成数组，所以声明时写成 String... args，实际接收类型是 String[]。
- 错误写法：
void method(String... args, int x)—— 编译不通过，varargs不能后跟其他参数 - 正确写法：
void log(String tag, Object... messages)—— 先固定参数，再varargs - 调用时可传 0 个、1 个或多个实参：
log("INFO")、log("WARN", "timeout")、log("ERROR", 404, "not found", true)
为什么不能重载两个只有 varargs 区别的方法
因为 varargs 在编译期会被“降级”为数组调用，导致签名冲突。例如 print(String... s) 和 print(String[] s) 无法共存——编译器会把 print("a", "b") 同时匹配到两者，报错 reference to print is ambiguous。
- 避免方式：改用不同方法名，或确保重载方法的非
varargs部分有明确区分（如不同类型、不同数量的前置参数） - 特别注意：调用
print(new String[]{"a", "b"})会走String[]版本；而print("a", "b")才走String...版本——但二者不能同时存在
在泛型方法中使用 varargs 要小心类型擦除
泛型 + varargs 组合会触发编译器警告 Generic array creation，因为 JVM 运行时无法创建具体泛型数组（如 List<string>[]</string>），而 varargs 底层需要分配数组。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 典型警告代码：
<T> void addAll(T... elements) { ... }—— 编译通过但有unchecked警告 - 安全做法：用
Collection<T>替代，或接受警告并加@SafeVarargs（仅限static或final方法） - 反例：
new ArrayList<String>[5]直接编译失败，这正是varargs在泛型里受限的根本原因
性能与实际使用中的隐含开销
每次调用带 varargs 的方法，JVM 都要新建一个数组来承载参数，哪怕只传一个值或零个值。对高频调用（如日志、序列化工具方法），这个分配可能成为瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 零参数调用：
debug()→ 仍会分配一个长度为 0 的Object[0] - 单参数调用：
debug("ok")→ 分配Object[1]，而非复用已有对象 - 优化建议：对性能敏感路径，提供重载的「零参数」和「单参数」版本（如
debug()、debug(String msg)、debug(String msg, Object... args)），避免无谓数组分配
ClassCastException。 
