varargs必须放在参数列表最后，因为jvm需靠位置区分固定参数与可变部分；它本质是数组语法糖，声明为string...，方法内为string[]，传参时单值自动装箱、多值展开、显式数组需加...后缀。
varargs 必须放在参数列表最后
Java 里 ... 表示可变长参数，但它不是想放哪就放哪的。如果它不在参数列表末尾，编译器直接报错：Variable arity method declaration not allowed here。
常见错误是写成这样（错）：
public void log(String... args, int level) { ... }
正确写法只能是：
public void log(int level, String... args) { ... }
- 因为 JVM 需要靠「位置」来区分固定参数和可变部分，前面的固定参数必须能被明确匹配
- 如果有重载方法，比如同时存在
log(String)和log(String...)，调用log("a")会优先匹配前者——...是兜底机制，不是默认首选 - 不能有两个
...参数，语法不允许
varargs 实际上就是数组，但传参方式有区别
声明时写 String...，方法体内拿到的是 String[]，这点很关键。很多人以为它是“新类型”，其实只是语法糖。
立即学习“Java免费学习笔记（深入）”；
所以你可以直接对 args 调用 .length、用 for-each 遍历，甚至传给需要 String[] 的其他方法。
- 调用时传单个值：
print("hello")→args是长度为 1 的数组 - 传多个值：
print("a", "b", "c")→args是长度为 3 的数组 - 显式传数组需加
...后缀：print(arr)报错，必须写print(arr...)，否则会被当作一个元素（即String[]类型的单个参数）
和 Object... 混用时的类型擦除陷阱
泛型方法 + varargs 容易出 Generic array creation 错误，典型如：<t> void foo(T... items)</t>。
这是因为 Java 在运行时擦除了 T，但 varargs 内部要创建数组，而泛型数组禁止创建。
- 编译器会悄悄生成桥接方法并警告
unchecked generic array creation - 实际运行中如果传入不同子类型（比如
foo("s", 123)），可能在方法体内触发ArrayStoreException - 安全做法是改用
Collection<t></t>或明确类型，比如String...、Runnable...
性能与可读性权衡：别为了省一个数组括号滥用 varargs
varargs 方便，但每次调用都会新建数组对象，哪怕只传一个参数。
高频调用场景（如日志、数值计算工具方法）中，这个开销不可忽略。
- JIT 可能在某些简单 case 下优化掉数组分配，但不保证，也不该依赖
- 如果方法本就只接受 1–3 个参数，考虑重载更清晰：
max(int a)、max(int a, int b)、max(int a, int b, int c) - 对外 API 设计时，varargs 让调用方“感觉”更灵活，但内部实现要意识到它本质是数组 —— 尤其做 null 判断时，
args本身可以是null（虽然很少见），而空参调用得到的是空数组，不是null
null 显式传入、重载冲突、和反射一起用，容易漏掉判断。真要压榨性能或对接底层，还是得回到数组本身。 
