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