PECS原则通过明确读写意图消除冗余强制转换：只读用<? extends T>免转型取值，只写用<? super T>免转型插入，成对使用避免中间强转链，使不安全转换根本无法编写。
PECS原则本身不直接“减少代码冗余”，但它通过在编译期明确集合的读写意图，从根本上消除了大量本不该存在的强制类型转换逻辑。这不是靠删代码实现的精简，而是让那些危险、多余、本应被编译器拦下的转换根本写不出来。
只读时用 ? extends T：读取即安全，无需转型
当你只从集合中读数据，并按父类或接口使用时，? extends T 告诉编译器：“这里面出来的每个元素，都能当 T 用”。编译器据此允许你直接调用 T 定义的方法，不加任何 cast。
- 比如
List<? extends Number>，遍历时可直接写num.doubleValue()，不用((Double) num).doubleValue()或(Number) num - 传入
List<Integer>、List<BigDecimal>都合法，且所有读操作都免转换 - 如果错误地写了强制转换，比如
(Integer) list.get(0)，编译器反而会报错——因为实际类型不确定，这种转换本身就是不安全的冗余操作
只写时用 ? super T：添加即兼容，不靠运行时兜底
当你主要往集合里塞数据，且这些数据是 T 或其子类时，? super T 放宽了目标容器的类型要求，让方法能接收更宽泛的集合类型，而无需在调用前手动包装或转型。
- 例如方法
void addStudents(Collection<? super Student> target)可以安全接收ArrayList<Student>、LinkedList<Person>甚至HashSet<Object> - 你调用
target.add(new Graduate())时，编译器确认它一定兼容——不需要提前把Graduate转成Person或Object再塞进去 - 反过来，如果没用 PECS，你可能得为每种目标类型写一个重载方法，或者用
Collection<Object>然后自己做一堆 instanceof + 强转，这些全是冗余且易错的逻辑
上下游协作时：避免中间层擦除+强转链
真实业务中，数据常从一个集合流向另一个。PECS 成对使用，让流转过程保持类型语义清晰，跳过不必要的中间转换。
- 比如从
List<Student>过滤出高分者，再批量加入Set<Person>：用Collection<? super Person>接收目标，直接 add，不需先转成Person实例再塞 - 若用原始泛型（如
Collection<Person>），你就无法把List<Student>传进去，只能手动遍历、强转、再 add——这就是典型的因类型不匹配催生的冗余转换逻辑 - PECS 不增加运行时开销，也不改变字节码结构，只是让编译器在擦除前就帮你守住边界，把“靠人肉保证类型正确”的部分，变成“不这么写就通不过编译”
它不减少代码行数，但大幅减少了那些本不该存在、只为绕过类型系统限制而写的转换语句。类型安全和简洁性，在这里是一体两面。
