ArrayUtils 不需要 PECS 原因在于其基于数组协变性和方法重载，而非泛型容器的读写边界；它直接操作具体数组类型，依赖运行时类型检查与底层 arraycopy，不涉及 ? extends T 或 ? super T 的泛型通配符。
PECS（Producer Extends, Consumer Super）原则在 ArrayUtils 的组合方法中并不直接体现，因为 ArrayUtils 主要处理原始类型和对象数组，其方法设计面向实用性而非泛型协变/逆变的复杂约束。它不依赖通配符泛型参数，而是通过方法重载和类型擦除兼容性来支持多类型数组合并。
为什么 ArrayUtils 不需要 PECS
ArrayUtils.addAll() 等组合方法接受的是具体数组类型（如 String[]、int[]、Object[]），而非泛型集合。Java 数组本身是协变的（String[] 是 Object[] 的子类型），所以方法可自然接收子类型数组作为参数，无需 ? extends T。同时，它不返回泛型集合，也不涉及“生产”或“消费”的泛型容器边界判断。
- 方法签名是扁平重载，例如：
addAll(String[], String[])、addAll(int[], int[])、addAll(Object[], Object[]) - 没有使用
List<? extends T>或List<? super T>这类泛型通配符参数 - 底层靠
System.arraycopy和类型检查（如Array.newInstance）保障运行时安全，而非编译期泛型约束
对比：PECS 典型场景 vs ArrayUtils 实际做法
若强行将 PECS 思维套用到数组合并，会发现它不适用：
- PECS 关注的是“泛型容器中元素的读写倾向”——比如
Collection<? extends Number>只能取（producer），不能加（consumer）；而ArrayUtils.addAll()是“全量复制”，既读源数组又写目标数组，且目标数组类型必须明确、不可变 - 数组合并要求目标数组类型能容纳所有源元素，这靠 Java 数组协变规则自动满足（如
Object[]可接收String[]和Integer[]），而不是靠通配符下界或上界推导 -
ArrayUtils提供toObject()、toPrimitive()等桥接方法，本质是类型转换，不是泛型边界适配
真正影响 ArrayUtils 组合行为的关键机制
它依赖的是 Java 数组的底层特性与实用主义设计，而非泛型边界：
立即学习“Java免费学习笔记（深入）”；
-
协变性利用：允许
String[]赋给Object[]参数，使addAll(Object[], Object[])可通吃多数引用类型数组 -
原始类型特化：为
int[]、long[]等单独提供重载方法，绕过泛型无法支持基本类型的限制 -
运行时类型检查：对不兼容类型（如尝试把
int[]加到String[]）抛出IllegalArgumentException，而非编译期拦截
延伸提醒：何时才该想到 PECS
当你操作的是 List<T>、Collection<E> 等泛型集合，并设计通用工具方法时，PECS 才真正起作用。例如：
- 一个泛型工具方法接收多个
List<? extends Animal>并只读取元素 → 用extends（producer） - 一个方法向
List<? super Dog>中添加Dog实例 → 用super（consumer） -
ArrayUtils没有这类泛型集合参数，因此它的设计逻辑与 PECS 分属不同抽象层次
