不传参时返回的是 Object[]，问题在哪

调用 list.toArray() 无参方法时，返回的是一个 Object[] 数组。如果你期望得到具体类型的数组，比如 String[]，后续必须进行强制类型转换。一旦 list 中包含非 String 元素，强制转换就会在运行时抛出 ClassCastException。这种错误在编译期无法发现，只有运行到该代码时才会暴露，增加了调试成本。

在实际项目中，我见过不少人图省事直接用无参 toArray()，然后强转。结果某个业务分支塞进了 Integer，线上就开始抛异常。而且因为强转的地方可能离数据插入点很远，排查起来特别费劲——你往往要翻日志、翻堆栈，最后发现是类型不匹配。所以如果你对返回的数组有类型要求，传参是必须的。

为什么 toArray(T[]) 能返回正确类型

无参 toArray() 方法只能返回 Object[]，因为它在泛型擦除后失去了具体类型信息。而 toArray(T[]) 方法通过传入的数组参数的类型信息，可以借助反射在运行时创建正确类型的数组。如果不传参，方法内部只能使用 new Object[size] 来分配数组，从而失去了类型安全性。

简单来说，你传入的数组给 JVM 提供了一个“类型模板”。比如你传 new String[0]，即使数组长度为 0，方法的内部逻辑也能通过 array.getClass().getComponentType() 拿到 String.class，然后用反射 new 出一个 String[]。这就是为什么空数组也能生效的原因。

最佳实践：推荐传入空数组

推荐传入一个空数组，例如 list.toArray(new String[0])。这种方式既能保证返回类型正确，又不会因为传入的数组长度大于列表而浪费分配空间。JVM 会利用传入数组的运行时类型创建新数组，性能通常优于传入一个预分配大小的数组。从 Java 5 起，这种写法已成为标准模式。

有些人可能觉得传空数组会多一次反射调用，性能不如传一个预分配大小的数组。但很多实际测试（比如 JDK 内部的优化以及 Stack Overflow 上的讨论）表明，空数组写法在现代 JVM 上并不慢，甚至因为避免了多余的数组分配而更快。而且代码更简短，意图更明确。如果你不放心，可以结合你项目的性能测试做决定，但保守建议先按标准模式写。

常见误区和边界处理

一个常见的错误是传入一个长度刚好等于列表大小的数组，以为可以避免创建新数组。但实际上，toArray 方法仍然可能创建新数组，即使传入的数组大小足够，也不保证直接使用该数组。此外，如果传入的数组更大，多余元素会被置为 null，可能导致后续使用时出现空指针。因此，最保险的做法是传入空数组。

那什么时候可以传非空数组呢？如果你明确需要复用已分配的数组空间，并且能接受后续可能出现 null 元素，可以传一个长度大于或等于列表的数组。但要注意，toArray 方法内部实现可能因 JDK 版本不同而有差异，比如 OpenJDK 8 中，如果数组大小足够，会直接把元素复制进去并返回该数组，不会新建。但这不是规范保证的，依赖这个行为有风险。所以我个人建议：除非你做过充分的压力测试和版本兼容验证，否则还是用空数组。

什么时候可以不用传参？

当列表为空时，传入空数组仍然返回一个空数组，类型正确。如果不传入参数，则返回一个空的 Object[]，这通常能满足需要，但若要赋值给具体类型数组仍需强转或加泛型。注意，传入 null 作为数组参数会抛出 NullPointerException，这一点在旧版 JDK 文档中有明确说明。

如果你确实只是需要一个 Object[]，或者代码只内部使用且已经包装好了泛型，不传参也没问题。但一旦你把这个数组暴露给外部接口，或者需要把它传递给期望具体类型的方法，就必须传参。另外，如果你用的是 Java 11+，List 新增了 toArray(IntFunction) 方法，可以传一个生成器，但本质也是通过函数式接口提供类型信息，与 toArray(T[]) 类似。

总之，记住一句话：如果对返回类型有具体需求，就传一个空数组；如果不在乎类型且只用于临时读取，无参返回的 Object[] 也能用，但别强转。这两种场景下，你的代码都清晰可维护。