itemreader是生产者，用? extends t安全读取子类型数据；itemwriter是消费者，用? super t安全写入父类型兼容数据，二者共同体现pecs原则。
PECS（Producer Extends, Consumer Super）是 Java 泛型中关于通配符使用的核心原则，它直接指导我们如何安全地读写泛型集合。Spring Batch 的 ItemReader 和 ItemWriter 接口设计，正是 PECS 原则的典型体现——一个只产出数据，一个只消费数据，职责清晰、类型安全。
ItemReader 是典型的 “Producer”，用 ? extends T
ItemReader<t></t> 接口定义为：
public interface ItemReader<t> {
T read() throws Exception;
}</t>
它每次调用 read() 方法，**向外提供（produce）一个 T 类型的实例**，比如 User、Order 或 String。它不接收任何输入，只单向输出。
因此，当你把 ItemReader extends Person> 作为参数传入某方法时，该方法可以安全地调用 read() 并得到一个 Person 或其子类（如 Employee）的对象——这正是 Producer Extends 的适用场景。
常见误用示例：
- 写成
ItemReader<object></object>去读User数据 → 类型太宽，编译通过但语义丢失，无法保证返回值是预期子类型； - 试图往
ItemReader里塞数据（比如设值）→ 接口根本不提供写入能力，违背其 producer 本质。
ItemWriter 是典型的 “Consumer”，用 ? super T
ItemWriter<t></t> 接口定义为：
public interface ItemWriter<t> {
void write(List extends T> items) throws Exception;
}</t>
注意：方法参数是 List extends T>，但整个接口的泛型参数 T 表示它**能接受（consume）T 及其任意子类型的对象列表**。也就是说，ItemWriter<person></person> 不仅能写 Person 实例，也能写 Employee、Customer 等子类实例——只要它们是 Person 的子类型。
这就对应 PECS 中的 Consumer Super：若你希望一个 writer 能处理更宽泛的输入（比如所有 Person 子类），应声明为 ItemWriter super Person>，这样你就能传入 ItemWriter<object></object> 或 ItemWriter<person></person> 等兼容类型。
实际开发中更常见的写法是直接使用具体类型：
-
@Bean public ItemWriter<user> userWriter() { ... }</user>→ 明确语义，推荐； - 若需复用 writer 处理多种子类型，可考虑上界通配符，例如方法签名：
void configureWriter(ItemWriter super User> writer)； - 避免写成
ItemWriter extends User>→ 这意味着“只能写未知的 User 子类”，但你根本不知道具体是什么类型，无法安全传入任何实例，编译会拒绝。
对比总结：读出 vs 写入，方向决定通配符
二者在 PECS 下的差异本质是数据流向不同：
-
ItemReader<t></t>是 生产者：向外吐T，所以适合? extends T（向上兼容，读得更具体）； -
ItemWriter<t></t>是 消费者：向内收T，所以适合? super T（向下兼容，写得更通用）； - Spring Batch 框架本身没有在接口中硬编码通配符，但它的方法签名（
read()返回T，write(List extends T>)）已隐含 PECS 意图，开发者在组合、泛型抽象或封装工具类时必须遵循； - 违反 PECS 往往导致编译错误或运行时类型异常，比如把
ItemWriter<employee></employee>强转为ItemWriter<person></person>会失败——因为Employeewriter 不能安全处理任意Person实例（可能含Customer字段）。
理解这点，能帮你写出更健壮的泛型批处理组件，也更容易看懂 Spring Batch 源码中各类 reader/writer 的泛型约束逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
