Java8中Stream.generate非变而Optional.orElseGet协变的原因是什么？

核心差异点：泛型参数的归属不同 #

两个方法的泛型T来源完全不一样，这是设计差异的根本原因：

• Stream.generate是静态泛型方法，它的<T>是方法自身声明的，调用时可以由编译器推导，或者用户显式指定，灵活度极高
• Optional.orElseGet是实例方法，它的T是Optional类声明的泛型参数，只要Optional对象的类型确定（比如Optional<Animal>），这个T就完全固定，调用方法时无法修改

为什么orElseGet要设计成协变 #

Optional的T是类级固定的，按照PECS规则，Supplier是生产者（只产出值，不消费值），所以需要用? extends T来扩大入参的兼容范围：
假设我们有Optional<Animal>，我们希望缺省值可以是任何Animal的子类实例，比如Cat、Dog都合法。如果参数设计为Supplier<T>（也就是Supplier<Animal>），由于Java泛型是不变的，Supplier<Cat>无法直接传给Supplier<Animal>，会直接编译失败。
加了? extends T之后，所有生产T及T子类的Supplier都可以传入，完全符合使用需求。

为什么generate设计成非变 #

Stream.generate的T是方法级的，本身就可以根据上下文灵活调整，不需要通配符就能支持所有协变场景：

• 如果你传Supplier<Cat>，编译器默认会把T推导为Cat，直接返回Stream<Cat>
• 如果你需要得到Stream<Animal>，只需要显式指定方法泛型：Stream.<Animal>generate(catSupplier)就能实现，完全没有障碍
  如果给generate的参数加? extends T，属于冗余设计，不会带来额外的灵活性，反而会让方法签名变得更复杂。

协变/非变的判断原则 #

1. 优先遵循PECS规则：
   • 只产出数据的生产者参数，用? extends T协变
   • 只接收数据的消费者参数，用? super T逆变
   • 既要读又要写的参数，用不变的T
2. 结合泛型参数的归属判断：
   • 如果泛型是方法自身声明的，和返回值直接绑定、可以灵活推导的，不需要额外加通配符，用户可以通过显式指定泛型实现灵活适配
   • 如果泛型是类级别固定、调用方法时无法修改的，必须按PECS加通配符，保证使用灵活性

内容的提问来源于stack exchange，提问作者Guo