PECS原则明确泛型通配符的职责边界：? extends T用于只读生产者，保证安全获取T及其子类；? super T用于只写消费者，支持添加T及子类但获取仅限Object。
泛型上限（? extends T）和下限（? super T）不是为了描述“类型多大”或“继承多深”，而是为组件设计划清职责边界：一个容器该读，还是该写。PECS 原则把这种分工提炼成一句可落地的工程口诀——它不抽象，也不玄学，直接决定你写的接口能不能被安全复用。
上限 ? extends T：只读容器，是生产者
当你设计一个组件，它的核心职责是从集合中提取、转换、校验或消费数据（比如统计求和、格式化打印、类型判断），那它就是生产者。此时用 ? extends T，让调用方传入任意 T 或其子类的集合。
- 能安全 get：编译器保证每个元素都是 T 类型或其子类，可直接调用 T 的方法（如
doubleValue()、toString()） - 禁止 add/set：哪怕传 new T()，编译器也拒绝——因为实际可能是
ArrayList<Integer>，却想塞进Double，会破坏类型一致性 - 典型场景：工具方法
sum(List<? extends Number> list)、printAll(Collection<? extends Animal> animals)
下限 ? super T：只写容器，是消费者
当你设计一个组件，它的核心职责是接收、收集、归并或暂存数据（比如日志收集器、批量导入器、事件总线），那它就是消费者。此时用 ? super T，允许调用方传入 T 或其任意父类的集合。
- 能安全 add：任何 T 实例（包括子类对象）都能放进目标容器，因为上层类型（如
Object、Serializable）一定兼容 - get 返回只能是 Object：你无法确定取出的是 T 还是更宽泛的类型，所以必须显式转型或仅作通用处理
- 典型场景：集合工具方法
Collections.<T>addAll(Collection<? super T> c, T... elements)、自定义缓冲区void feed(Event e)接收List<? super ClickEvent>
PECS 是接口契约，不是语法技巧
在组件设计中，PECS 不是“选个通配符凑合用”，而是对外暴露的契约声明：
- 写
<? extends Request>，等于告诉使用者：“我只取请求，不改你列表；你可以放心传ArrayList<LoginRequest>或LinkedList<SearchRequest>” - 写
<? super Response>，等于承诺：“我能收所有响应子类，你传ArrayList<Object>、Vector<ApiResponse>都行；但我取出时只敢当Object处理” - 如果一个方法既 get 又 add，说明这个组件职责混乱——要么拆成两个独立方法，要么放弃通配符，用具体泛型参数
<T>显式约束
常见设计陷阱与规避方式
很多组件接口看似灵活，实则因违背 PECS 而难以复用：
-
误用上限做写操作：如
void process(List<? extends String> list)内部尝试list.add("x")→ 编译失败，String 是 final 类，但逻辑错误本质不变 -
误用下限做精确读取：如
String first = list.get(0)在List<? super Integer>上 → 编译报错，只能赋给Object -
过度泛化导致调用方困惑：接口返回
List<?>而非List<? extends Product>→ 调用方无法安全使用元素，失去泛型价值
