为什么 list.toArray() 返回 Object[] 而不是你想要的类型数组
Java 泛型擦除导致 list.toArray()（无参重载）只能返回 Object[]，哪怕你的 List<string></string> 里全是字符串。这不是 bug，是类型系统设计决定的——运行时根本不知道泛型参数是什么。
常见错误现象：String[] arr = list.toArray(); 编译直接报错：「incompatible types: Object[] cannot be converted to String[]」。
- 必须用带参重载：
list.toArray(new String[0])或list.toArray(new String[list.size()]) - 传入空数组（
new String[0]）更安全：避免因数组长度不足触发内部扩容，JVM 会新建正确大小的数组 - 传入非空数组（如
new String[5]）且列表元素少于 5 个时，多出的位置会被设为null；多于 5 个则新建数组——这可能引发 NPE 或隐藏容量问题
toArray(T[]) 的数组长度怎么选：0、size 还是 size+1
核心原则：传 new T[0] 是当前最推荐写法，尤其在 Java 11+。它明确表达“我要一个新数组”，且 JVM 已针对该模式做了优化。
-
new T[0]：安全、简洁、语义清晰；现代 JVM 性能不输预分配 -
new T[list.size()]：看似省一次扩容，但若 list 是并发修改的（比如被其他线程 add），size()和后续toArray执行之间可能不一致，导致数组末尾多出null -
new T[list.size() + 1]：旧文档曾建议这个来避免扩容，但实际没必要；反而容易让调用方误以为数组可写入额外元素，引发逻辑错误
原始类型数组不能直接用 toArray ——别试了
int[]、double[] 这类原始类型数组，toArray 完全无法生成。因为泛型只支持引用类型，List<int></int> 本身就不合法（只能是 List<integer></integer>）。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：int[] arr = list.toArray(new int[0]); 编译失败：「no suitable method found for toArray(int[])」。
- 必须手动转换：用
stream().mapToInt(Integer::intValue).toArray() - 注意性能：
Stream方式有装箱/拆箱开销，大数据量时比传统 for 循环慢；若性能敏感，老老实实写 for - 第三方库如 Guava 的
Ints.toArray(Collection<integer>)</integer>可读性更好，但引入依赖需权衡
并发场景下 toArray 的隐性风险
如果 List 是 Collections.synchronizedList 或 CopyOnWriteArrayList，toArray 行为差异很大，但文档没明说。
-
CopyOnWriteArrayList.toArray()返回的是快照，线程安全，但数组内容可能已过期 -
synchronizedList的toArray()不自动加锁！必须手动同步：synchronized(list) { list.toArray(...) }，否则可能抛ConcurrentModificationException或返回截断/重复数据 - 即使加了 synchronized，如果 list 是子类自定义实现，仍要查其
toArray是否保证原子性——别默认它安全
toArray 行为不统一，以及原始类型那块永远绕不开的手动映射。 
