toarray() 返回 object[] 是因泛型擦除导致运行时无法创建具体类型数组；正确做法是传入 new t[0]，jdk 11 起官方推荐此方式，语义清晰且内存友好。
toArray() 方法为什么返回 Object[] 而不是泛型数组
Java 的 Collection.toArray() 默认返回 Object[]，这是由泛型擦除决定的：运行时无法知道泛型类型，JVM 无法安全创建 String[] 或 Integer[] 这类具体类型的数组。直接强制转型（如 (String[])list.toArray()）在运行时会抛出 ClassCastException，尤其当集合实际是 ArrayList 且底层用 Object[] 存储时——转型失败不是因为内容不对，而是数组实例本身的运行时类型就是 Object[]。
- 不要写
(T[])list.toArray()—— 这是不安全的，编译警告且可能崩溃 - 正确做法是调用带参数的重载：
list.toArray(new String[0])或list.toArray(new String[list.size()]) - 传入空数组（
new String[0]）更推荐：它让方法内部决定数组大小，避免冗余分配；多数 JDK 实现会复用该数组或新建恰好大小的数组
使用 toArray(T[]) 时传 new T[0] 还是 new T[size]？
两者都能工作，但行为不同：new String[0] 触发内部逻辑新建一个大小刚好为集合长度的数组；而 new String[list.size()] 可能被直接填充并返回（某些实现），也可能被丢弃重建（如果集合并发修改导致 size 变化）。从 JDK 11 开始，官方文档明确建议优先使用 new T[0]。
-
list.toArray(new String[0])：语义清晰、内存友好、兼容所有 JDK 版本 -
list.toArray(new String[list.size()])：看似“省一次分配”，实则可能白建——比如CopyOnWriteArrayList在调用期间扩容，原数组会被抛弃 - 注意：不能传
null，否则抛NullPointerException
Stream API 的 toArray() 和传统方式有什么实质区别
stream().toArray(String[]::new) 是函数式写法，本质是通过构造器引用生成目标类型数组，绕过了泛型擦除限制。它和 list.toArray(new String[0]) 最终效果一致，但机制不同：前者依赖 IntFunction 在收集阶段动态创建数组；后者依赖集合自身实现的反射式数组分配。
- 性能差异极小，现代 JIT 基本抹平；但
Stream.toArray()多一次遍历开销（除非已用流） - 可读性上，
list.toArray(new X[0])更直白，适合简单转换；stream().map(...).toArray(X[]::new)适合需要中间操作的场景 - 注意：
stream().toArray()无参版本仍返回Object[]，必须用带构造器引用的重载
自定义集合或第三方库（如 Guava）的 toArray 行为是否可靠
只要实现遵循 Collection 接口规范，toArray(T[]) 就应保证返回指定运行时类型的数组。但部分轻量集合（如某些不可变包装类）可能缓存或共享数组，若返回的数组被外部修改，可能破坏集合内部状态。
立即学习“Java免费学习笔记（深入）”；
- Guava 的
ImmutableList安全：其toArray(T[])总是返回新数组，不共享内部数据 - 自己写的集合要特别注意：若复用内部数组并返回，必须确保该数组未被标记为“不可修改”或未被其他逻辑依赖
- 测试时别只看结果类型对不对，还要验证修改返回数组是否影响原集合（例如：赋值后调用
list.get(0)是否变化）
toArray(new String[0]) 返回 String[0]，但 toArray(new String[1]) 会返回填满 null 的 String[1]；再比如子类集合重写了 toArray 却没处理好协变性。动手前先看一眼你用的具体集合类的 Javadoc。 
