Java可变参数本质是编译器语法糖，编译后为数组类型，必须位于参数列表末尾；重载时null可能误触发varargs分支；泛型varargs有类型擦除警告且不支持基本类型。
Java可变参数本质就是数组，但不是所有数组都能当varargs传
Java的void foo(String... args)看着灵活，其实编译后就是void foo(String[] args)。JVM层面压根没有“可变参数”这个概念，只是编译器帮你做了语法糖转换：把逗号分隔的实参打包成一个新数组传进去。
这意味着你不能直接把已有的String[]当成String...来用——除非显式加...告诉编译器“别再包一层了”。否则会触发“array in array”错误。
- ✅ 正确：
foo("a", "b")或foo(arr)（如果arr是String[]） - ❌ 错误：
foo(new String[]{"a", "b"})—— 编译器会试图再套一层，变成String[][] - ⚠️ 特殊情况：
foo(new String[]{"a", "b"})实际能过，但这是历史遗留的“宽松模式”，不代表推荐；真正危险的是foo(arr)中arr为Object[]时，可能引发ArrayStoreException
重载+varargs容易掉进“最匹配陷阱”
当你同时定义了void bar(String s)和void bar(String... ss)，调用bar("x")一定走前者；但调用bar((String) null)或bar(null)就可能意外触发varargs分支——因为null对两者都“可接受”，而varargs版本在重载解析中属于“更宽泛的匹配”。
- 常见现象：
bar(null)抛NullPointerException，但堆栈指向bar(String...)内部空指针，而非你预期的单参版本 - 根本原因：重载解析阶段不检查运行时值，只看类型兼容性；
null可赋给String，也可赋给String[]，编译器选了后者 - 规避方式：要么删掉单参重载，要么把varargs方法改名（如
barAll），避免歧义
泛型方法+varargs会触发unchecked警告，且无法完全消除
写<T> void baz(T... items)时，编译器必须生成桥接方法，而泛型擦除导致它实际创建的是Object[]，再强制转型——这就是unchecked generic array creation警告的来源。
立即学习“Java免费学习笔记（深入）”；
- 你不能用
@SuppressWarnings("unchecked")精准标注到数组创建点，只能标在方法上，掩盖整个方法的类型安全风险 - 更麻烦的是：如果
T是基本类型（如int），代码根本编译不过——varargs只支持引用类型，int...会被自动装箱为Integer...，但<T> void qux(T...)中的T无法推导为int - 性能提示：每次调用都会新建数组，哪怕只传一个元素；高频场景建议提供重载（如
qux(T a)、qux(T a, T b)）避开varargs开销
varargs参数必须是方法最后一个形参，且不可跟在普通参数之后再出现其他参数
语法强制要求...出现在参数列表末尾，这是为了保证调用时参数顺序无歧义。一旦违反，编译器立刻报错varargs parameter must be the last parameter。
- ❌ 非法：
void doit(String... xs, int y)→ 编译失败 - ❌ 非法：
void doit(int x, String... ys, boolean z)→ 同样失败 - ✅ 合法：
void doit(int x, String... ys)，此时ys接收从第二个参数开始的所有String实参 - ⚠️ 注意：
doit(1)会让ys变成长度为0的数组，不是null——这点常被忽略，判空要用ys.length == 0，而不是ys == null
varargs看着省事，但它的数组本质、重载行为、泛型限制和语法位置都是硬约束。写的时候多想半秒“这玩意到底生成了什么数组”，比事后查ArrayIndexOutOfBoundsException快得多。
