allOf 无法过滤结果，需用 handle() 统一处理每个 CompletableFuture 的成功/异常并转为 null，再通过 stream.filter(Objects::nonNull) 实现安全过滤；必须显式指定线程池防阻塞，并校验 isCompletedExceptionally() 避免静默失败。
allOf 本身不提供结果过滤能力，必须手动遍历原始 CompletableFuture 列表
CompletableFuture.allOf 返回的是 CompletableFuture<void></void>，它只做“等待全部完成”这件事，既不保存原始类型，也不支持中间过滤。所谓“结果过滤器”，其实是你在 allOf().join() 之后，对每个已启动的 CompletableFuture 实例单独调用 join() 或 get()，再用 Java Stream 或 if/else 做逻辑筛选。
常见错误是试图在 allOf 的返回值上链式调用 thenApply 去过滤——这根本走不通，因为返回类型是 Void，没有值可 map。
- 所有待过滤的 future 必须提前构造并启动（例如用
supplyAsync或 HTTP 客户端调用），不能延迟触发 - 推荐把它们存进
List<completablefuture>></completablefuture>，而不是临时拼数组，避免引用丢失或执行顺序错乱 - 如果某个 future 抛异常，
join()会直接抛出CompletionException，所以过滤前得先处理异常分支
用 handle() 在每个 future 上做安全取值 + 条件跳过
想实现“只保留非 null、非空、不报错的结果”，不能等全部 join() 完再 filter，而应在每个 future 上用 handle() 统一封装成功/失败路径，让结果流天然可过滤。
示例：三个微服务返回 User、Order、Product，但允许其中某一个不可用：
List<CompletableFuture<Object>> futures = Arrays.asList(
userF.handle((u, t) -> t == null && u != null ? u : null),
orderF.handle((o, t) -> t == null && o != null ? o : null),
productF.handle((p, t) -> t == null && p != null ? p : null)
);
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
List<Object> filtered = futures.stream()
.map(CompletableFuture::join)
.filter(Objects::nonNull)
.collect(Collectors.toList());
-
handle()是关键：它无论成功或异常都会执行，第二个参数t是异常，第一个v是正常值；用它把异常/空值统一转为null，后续filter(Objects::nonNull)才有效 - 不要用
exceptionally()单独兜底——它只捕获异常，不处理正常返回null的情况 - 注意
handle()返回的新 future 类型仍是CompletableFuture<object></object>，要确保泛型一致，否则 stream 操作会报错
allOf 等待期间线程池阻塞风险直接影响结果收敛可靠性
微服务调用本质是 I/O 操作，若用默认的 ForkJoinPool.commonPool()，一旦某个 HTTP 请求因超时未设或网络抖动卡住，就会吃掉 commonPool 线程，导致后续所有 join() 调用被拖慢甚至死锁——此时你看到的“结果收敛失败”，其实不是逻辑问题，而是线程资源耗尽。
- 所有涉及 HTTP、DB、RPC 的
CompletableFuture，必须显式指定自定义线程池，例如supplyAsync(() -> call(), httpClientPool) - 线程池建议用
ThreadPoolExecutor配合LinkedBlockingQueue，拒绝策略设为CALLER_RUNS，避免请求丢失 - 别依赖
allOf().orTimeout(3, SECONDS)——它只给 allOf 本身设超时，不作用于子 future；真正要控制的是每个微服务调用的 connect/read timeout
结果收敛后仍需检查 isCompletedExceptionally() 防止静默失败
allOf().join() 成功返回，不代表所有子任务都成功了。只要有一个 future 内部抛异常，allOf 仍会以“完成”状态结束（只是内部状态为 exceptional）。如果你跳过逐个检查，直接 join() 取值，异常会在那一刻才爆发，导致收敛逻辑中断或数据缺失。
- 收敛前加一层校验：
futures.stream().anyMatch(CompletableFuture::isCompletedExceptionally) - 若发现异常 future，可用
toCompletableFuture().getNow(null)尝试获取默认值，或走降级逻辑 - 生产环境建议记录每个 future 的完成状态和异常堆栈，比如用
whenComplete((v, t) -> log.info("userF done: {}, err: {}", v, t))
实际写聚合逻辑时，最易忽略的是：异常 future 的 join() 不会自动跳过，也不会返回 null，而是立即抛出 CompletionException —— 这意味着你写的过滤代码还没跑，程序就崩了。 处理它的唯一可靠方式，是在每个 future 上预置 handle() 或 exceptionally()，把“异常语义”转成“业务语义”。
