@MethodSource方法必须返回Stream<Arguments>，因其作为参数生产者需严格产出Arguments实例以供JUnit精确解包，使用? extends或? super Arguments均破坏类型契约导致运行时失败。
PECS（Producer Extends, Consumer Super）是 Java 泛型中关于通配符使用的核心原则，它指导我们何时用 ? extends T、何时用 ? super T。在 JUnit 5 的 @MethodSource 场景中，这一原则直接影响参数提供方法的签名设计——尤其是返回类型如何声明，才能既满足框架约束，又保持类型安全与可读性。
为什么 @MethodSource 方法必须返回 Stream<Arguments>？
JUnit 5 要求 @MethodSource 引用的方法返回 Stream<Arguments> 或 Iterable<Arguments>、Iterator<Arguments>、Arguments[] 等兼容类型。其中 Arguments 是一个不可变容器，用于封装一组测试参数（如 Arguments.of("a", 1, true)）。关键点在于：
-
Arguments本身不参与泛型协变/逆变，但它的生产者（即工厂方法）需明确其“产出”角色 - 方法作为 参数生产者，应向外提供具体参数组合 → 符合 Producer Extends
- 所以若你想返回更宽泛的类型（如
Stream<? extends Arguments>），编译会失败——因为 JUnit 运行时需要确切知道如何解包每个元素，而通配符会让类型擦除后无法匹配Arguments的结构
实际编码中如何体现 PECS 思维？
虽然不能对 Arguments 本身加 extends，但在构造参数时，PECS 原则体现在你如何组织入参对象的类型声明。例如：
- 若工厂方法生成的是
User实例，而测试方法接收User或其父类（如Person），那么你在Arguments.of(...)中传入User是安全的——因为User是Person的子类，符合“Producer Extends”的语义：生产者可以产出更具体的子类型 - 反过来说，如果测试方法形参是
Consumer<? super Person>（极少出现在测试方法中，但逻辑上成立），那工厂方法就该考虑提供Person或其任意父类实例——不过这在 JUnit 参数化中几乎不出现，因测试方法参数是固定声明的
常见错误：误用 ? super Arguments
有人尝试写成 Stream<? super Arguments> 或 Stream<Object> 并强转，这是典型的 PECS 误用：
立即学习“Java免费学习笔记（深入）”；
-
Arguments是消费者要“消费”的目标类型，不是你要往里塞东西的容器；工厂方法不是“消费者”，而是“生产者” -
? super Arguments意味着该 Stream 可以接受Arguments或其任意父类（如Object），但这违反了 JUnit 对参数结构的契约：它必须能精确识别每个字段对应哪个形参 - 运行时会抛出
ClassCastException或参数绑定失败，因为 JUnit 内部按Arguments的 API 解析，而非泛型通配符
最佳实践：用具体类型 + Arguments.of() 显式构造
最清晰、最符合 PECS 直觉的方式是：
- 工厂方法返回
Stream<Arguments>（不带通配符） - 用
Arguments.of(a, b, c)构造，其中每个参数类型与测试方法形参一一匹配 - 若涉及继承，确保传入的实参类型 ≤ 形参类型（如形参是
List<String>，传ArrayList<String>完全合法；形参是Number，传Integer也符合 Producer Extends）
