ArgumentCaptor本身不适用PECS原则，因其非容器类、无读写接口；它受类型擦除影响，只能用原始类型如Consumer.class初始化，而PECS主要用于指导被测方法中泛型参数（如集合或函数式接口）的声明设计。
Mockito 的 ArgumentCaptor 本身不直接依赖 PECS 原则，但它在捕获泛型参数时，会受到 Java 泛型类型擦除和 PECS 所体现的“读写语义”影响。理解这一点，能帮你避开常见编译错误、写出更安全的断言代码。
为什么 PECS 不显式出现在 ArgumentCaptor 声明中
ArgumentCaptor 是一个泛型工具类（ArgumentCaptor<t></t>），它的泛型参数 T 表示你期望捕获的**实际参数类型**（如 Consumer<string></string>、List<order></order>）。它本身不是容器类，也不对外提供读/写接口，因此不适用 ? extends T 或 ? super T 这类通配符声明。
真正起作用的是 Java 的类型擦除机制——运行时所有泛型信息都已丢失，所以 ArgumentCaptor.forClass(Consumer.class) 是合法的，而 Consumer<string>.class</string> 则根本无法编译。
PECS 思维有助于设计被测方法的签名
当你用 ArgumentCaptor 捕获某个参数时，该参数往往来自被测对象的方法调用。如果这个方法接收的是泛型集合或函数式接口，PECS 就变得关键：
立即学习“Java免费学习笔记（深入）”；
OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。
- 若方法参数是生产者（只向外提供数据），比如
Function<t r></t>或Supplier<t></t>，应优先用? extends T——这样你传入Supplier<string></string>也能匹配Supplier extends CharSequence> - 若方法参数是消费者（只接收数据），比如
Consumer<t></t>或Predicate<t></t>，应优先用? super T——例如Consumer<object></object>可安全接收String，符合“下界消费”逻辑 - Mockito 捕获时，你实际拿到的是具体实例（如
consumer.capture()返回Consumer<string></string>），但方法签名若写成void process(Consumer super String> c)，测试时就更容易构造和验证
捕获泛型参数时的实际类型处理技巧
由于类型擦除，你无法在运行时获取泛型实参，但可通过以下方式保障类型安全：
- 用
@Captor注解替代手动 new：避免unchecked警告，且由 Mockito 自动完成类型推导@Captor private ArgumentCaptor<Consumer<String>> stringConsumerCaptor; - 捕获后验证行为，而非仅校验类型：比如对捕获到的
Consumer<string></string>调用accept("test")，再检查副作用（如某字段是否更新） - 若需断言泛型集合内容，不要依赖
instanceof或反射判断泛型，而是直接遍历元素做值校验：assertThat(capturedList).containsExactly("a", "b");
一个典型误用与修正示例
错误写法（试图绕过擦除，但编译失败）：
ArgumentCaptor<List<User>> captor = ArgumentCaptor.forClass(List<User>.class); // ❌ 编译报错
正确写法（接受擦除事实，聚焦行为验证）：
@Captor ArgumentCaptor<List<User>> userCaptor;<br>verify(service).save(userCaptor.capture());<br>assertThat(userCaptor.getValue()).hasSize(2).extracting("name").contains("Alice", "Bob"); 
