pecs原则是java泛型中通配符使用的核心准则：只读用? extends t（生产者），只写用? super t（消费者），既读又写则用精确泛型t；它依据操作方向而非继承关系判断，确保类型安全。
PECS 原则是 Java 泛型中关于通配符使用的核心经验法则，它不讲抽象理论，而是直指“这个泛型参数在当前上下文中是干啥的”——是往外提供数据（Producer），还是往里接收数据（Consumer）。理解它，关键不是背口诀，而是看操作方向。
Producer Extends：只读场景，用 ? extends T
当你从一个集合或方法返回值中**取数据、遍历、处理内容**，且不打算往里塞新东西时，它就是“生产者”。这时用 ? extends T，表示“里面的东西是 T 或它的子类”，你可以安全地把它们当作 T 来用。
- ✅ 允许：调用
get()、iterator().next()，结果能赋给 T 或其父类型（如Fruit f = list.get(0)） - ❌ 禁止：调用
add()、set()（连 new T() 都不行），因为编译器无法确认容器实际能接受什么子类型 - ? 示例：
List extends Number>可接收ArrayList<integer></integer>或LinkedList<double></double>，遍历时都能调用doubleValue()，但不能往里 add 任何数字——怕加错类型
Consumer Super：只写场景，用 ? super T
当你向一个集合或方法参数中**塞数据、收集结果、归并输入**，且不关心从中读出具体是什么时，它就是“消费者”。这时用 ? super T，表示“这个容器至少能装下 T 类型及其所有父类”，你一定能安全地把 T 实例放进去。
- ✅ 允许：调用
add(T)、addAll()，传入任意 T 实例（包括子类对象，只要类型兼容） - ❌ 禁止：把
get(0)的结果直接当 T 用（只能接成Object），因为容器可能是List<object></object>或List<serializable></serializable>，没法保证返回值精确类型 - ? 示例：
Collections.<integer>addAll(dest, src)</integer>中，dest参数声明为Collection super Integer>，这样ArrayList<number></number>和LinkedList<object></object>都能作为目标接收整数
别硬套继承关系，盯住角色和操作
很多人卡在“Apple 是 Fruit 的子类，那该用 extends 还是 super？”，其实问题不在类图，而在你对这个变量要做什么：
- 如果方法签名是
void process(List extends Fruit> fruits)→ 你只遍历打印名字，它是 Producer - 如果方法签名是
void collect(List super Apple> basket)→ 你不断往篮子里放苹果，它是 Consumer - 如果既要读又要写，比如
void swap(List> list, int i, int j)，那就别用通配符，直接用具体类型或泛型方法<t> void swap(List<t> list, ...)</t></t>
Kafka 场景中的自然体现
在构建 ProducerRecord<k v></k> 时，PECS 不是硬性约束，而是设计提示：
- 消息体
V是业务事件的产出（如OrderEvent、LogEvent），若需统一发送逻辑，用ProducerRecord<string extends event></string>—— Producer Extends，确保只读安全 - 消息键
K常用于分区计算，若多种 ID 类型（OrderId、UserId）都要塞进同一个 producer，可声明为ProducerRecord super Id, String>—— Consumer Super，让 producer 接收任意实现Id的键 - 日常开发中多数用具体类型（如
ProducerRecord<string string></string>），但一旦涉及多类型共用逻辑，PECS 就成了避免运行时ClassCastException的关键防线
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
