Collections.copy(dest, src) 是 PECS 原则的典范实现：src 为只读生产者（List<? extends T>），dest 为只写消费者（List<? super T>），编译期确保类型安全，仅执行 dest.set(i, src.get(i))，不扩容、不转型、职责单一。
Java 中 Collections.copy(dest, src) 是 PECS 原则最干净、最锋利的一次落地——没有冗余，没有妥协，通配符用得恰到好处，每一处设计都服务于“安全搬运”这一个目标。
参数类型就是角色宣言
方法签名直白宣告了两个集合的职责：
-
List<? extends T> src：只读生产者。它产出T或其子类实例，get()返回值可直接当T用，但禁止add()（连null都不行） -
List<? super T> dest：只写消费者。它能接收T及所有子类对象，set()或add()安全，但get()只能返回Object（类型信息被擦除）
这不是泛型炫技，而是把“谁负责出、谁负责进”刻进方法契约里。
编译器全程盯梢，不靠运行时补救
PECS 的威力在于编译期拦截非法组合：
立即学习“Java免费学习笔记（深入）”；
- ✅
copy(new ArrayList<Person>(), new ArrayList<Student>())：Student 是 Person 子类 →src能产，dest能收 - ✅
copy(new ArrayList<Object>(), new ArrayList<String>())：String → Object，合法 - ❌
copy(new ArrayList<String>(), new ArrayList<Object>())：Object 不是 String 子类 →src无法保证只产 String，编译失败
错误在写代码时就被挡住，而不是等到 ClassCastException 在深夜报警。
底层循环极度克制，只做一件事
源码逻辑就一行实质操作：
dest.set(i, src.get(i));
而它的安全，完全依赖两个通配符的配合：
-
src.get(i)返回T（由? extends T保证） -
dest.set(i, ...)接收T（由? super T保证）
没有转型，没有判空，没有兜底逻辑——因为类型系统已经把路铺平了。
不支持自动扩容，恰恰是 PECS 的清醒
很多人抱怨 Collections.copy() 要求 dest.size() >= src.size()，甚至抛 IndexOutOfBoundsException。但这不是缺陷，是原则的延伸：
- 它只管“搬”，不管“建容器”——职责单一
- 如果允许动态扩容，就得在内部调用
add()，而? super T的add()虽安全，却可能破坏目标列表原有结构（比如Arrays.asList()返回的不可变列表） - 强制显式准备容量，反而让调用方清楚意识到：这是覆盖式写入，不是追加
这种“不友好”，其实是对语义完整性的坚持。
