PECS原则指导泛型通配符使用：生产者用extends（保障读取安全），消费者用super（保障写入安全）；map中? super T表消费输入、? extends R表生产输出，flatMap同理但输出为Stream<? extends R>以支持扁平化生产。
PECS 原则（Producer Extends, Consumer Super）在 Java 泛型设计中用于指导通配符的合理使用，核心是：**作为生产者（提供数据）时用 extends，作为消费者（接收数据）时用 super**。这一原则虽不直接出现在 map 和 flatMap 方法签名中，但其泛型参数的设计逻辑与 PECS 的思想高度一致——尤其体现在类型边界对“输入”和“输出”角色的约束上。
map 的签名与“消费者→生产者”双重角色
map 方法签名：<R> Stream<R> map(Function<? super T, ? extends R> mapper)
-
T 是输入类型，被 mapper “消费” → 使用
? super T：允许传入能处理T或其父类型的函数（如Function<Object, String>可用于Stream<String>），符合“消费者用super” -
R 是输出类型，由 mapper “生产” → 使用
? extends R：函数返回值必须是R或其子类型，保证流后续能安全接收该结果，符合“生产者用extends” - 例如：
Stream<Integer>.map(Object::toString)合法，因为Object::toString是Function<Object, String>，满足? super Integer（Object是Integer的父类）和? extends String（String是自身）
flatMap 的签名强化了“生产者”的嵌套层级
flatMap 方法签名：<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper)
- 输入端仍为
? super T：mapper 消费每个T元素，保持与map一致的消费者逻辑 - 输出端变为
Stream<? extends R>：mapper 不再直接返回R，而是返回一个“生产R的流”，因此最外层Stream是生产者，内部元素类型需用? extends R约束 - 这种嵌套结构（
Stream<? extends R>）正是 PECS 在复合类型中的自然延伸：外层流产出元素，内层元素必须可安全赋给R - 例如：
Stream<String>.flatMap(s -> Arrays.stream(s.split("")))中，s.split("")返回String[]，Arrays.stream(...)生成Stream<String>，而String是R（此处即String）的子类型，满足? extends R
为什么不用 ? super R？——避免类型污染
如果输出端错误地写成 Stream<? super R>，意味着 mapper 可返回 Stream<Object> 这类更宽泛的流，但下游操作（如 collect(Collectors.toList())）将无法保证元素实际是 R 类型，破坏类型安全。PECS 的本质是保障“读取安全”（生产者用 extends）和“写入安全”（消费者用 super），flatMap 的输出供下游读取，必须严格遵循 extends。
对比：map 与 flatMap 的泛型差异源于数据形态变化
-
map：一对一转换 → 输出单个R→Function<T, R>直接体现super/extends分离 -
flatMap：一对多 + 扁平化 → 输出Stream<R>→ 多一层“生产者”封装，Stream<? extends R>中的? extends R是对内部元素的 PECS 应用 - 二者共同点：输入始终是消费者角色（
? super T），体现对上游类型的兼容性；输出始终是生产者角色（? extends ...），体现对下游类型的可赋值性
