thenCombine的泛型通配符设计旨在保障类型安全与组合灵活性：? extends U放宽输入约束，? super T和? super U支持通用函数接收，? extends V确保协变返回，使编译器能自动推断参数与返回类型，无需手动标注，同时禁止不安全写入。
thenCombine 的通配符组合签名不是为了炫技，而是为类型安全和灵活组合服务的。
为什么用泛型通配符？
它的完整方法签名是：
public <U,V> CompletableFuture<V> thenCombine(CompletableFuture<? extends U> other,
BiFunction<? super T, ? super U, ? extends V> fn)
这里三个通配符各自承担明确职责：
-
? extends U：允许传入任意子类型 CompletableFuture（比如CompletableFuture<String>可接受CompletableFuture<Object>的子类结果），放宽输入约束，但不破坏类型安全 -
? super T和? super U：让 BiFunction 能接收当前阶段结果类型T及其父类、另一阶段结果类型U及其父类——这意味着函数可以写得更通用（例如用Object接收两个参数），同时仍能推导出返回类型V -
? extends V：确保函数返回值可赋给V或其子类型，支持协变返回，避免强制转型
实际影响：你写代码时能做什么？
这种设计让你在多数场景下无需显式指定泛型，编译器能自动推断：
立即学习“Java免费学习笔记（深入）”；
- 传
CompletableFuture<Integer>和CompletableFuture<String>，函数参数自然就是(Integer, String) - 若函数返回
Long，返回的 CompletableFuture 就是CompletableFuture<Long>，不用手动标注 - 即使你把一个
CompletableFuture<Number>和CompletableFuture<Integer>组合，只要 BiFunction 声明接收Number和Integer，也能编译通过
注意边界：什么不能做？
通配符带来灵活性，也隐含限制：
- 不能向
CompletableFuture<? extends U>写入数据（因为具体子类型未知），但 读取是安全的 —— 这正符合 thenCombine 只读取结果的语义 - BiFunction 中若尝试将
T强转成具体子类（如(t, u) -> ((MyType)t).doX()），需自行判空或加 instanceof，编译器不帮你保底 - 返回类型
V必须与函数实际返回值匹配；若函数返回Object却声明V为String，编译失败
对比 plain Future 就明白价值
传统 Future 没有这类组合能力。它只提供 get() 阻塞等待，无法表达“等两个异步结果都到了再算一次”。thenCombine 的签名设计，本质是在静态类型系统内，为“并行+合并”这一常见模式提供了零运行时开销、强类型保障的抽象。它不牺牲安全，也不妥协表达力。
