并行网关聚合需自定义IO线程池、allOf仅作完成等待、每个调用独立兜底；禁用commonPool，用supplyAsync((), ioExecutor)显式传池；结果从原始Future取；每个Future用handle()兜底；聚合时校验null并封装轻量不可变VO。
用线程池配合 CompletableFuture.allOf 实现并行网关的变量聚合响应，核心不是“等完就完”，而是“等得稳、取得准、错得明、压得住”。关键在三点：线程池必须自定义、allOf 只管等待不存结果、每个服务调用要独立兜底。
必须换掉 commonPool，配专用 IO 线程池
微服务调用本质是阻塞型 I/O（HTTP/JSON），如果沿用 ForkJoinPool.commonPool()，一个慢接口就可能卡住整个线程池，导致后续所有异步任务排队、超时、雪崩。
- Spring Boot 中推荐配置独立线程池，比如命名为
ioExecutor，核心线程数设为 10–20，最大 50，队列容量 100，避免无界堆积 - 所有远程调用必须显式传入该线程池：
CompletableFuture.supplyAsync(() -> userServiceClient.get(1L), ioExecutor) - 别写
supplyAsync(() -> ...)不带参数的裸调用——这是线上事故高发点
allOf 只做“完成门控”，结果必须从原始 Future 拿
CompletableFuture.allOf(...).join() 返回的是 void，不是数据。它只告诉你“都跑完了”，但不会帮你收快递。
- 正确姿势：先保留每个服务的 Future 引用
CompletableFuture<User> userF = callUserService(id);<br>CompletableFuture<Order> orderF = callOrderService(id);<br>CompletableFuture<Product> productF = callProductService(sku);
- 再用 allOf 统一等待：
CompletableFuture.allOf(userF, orderF, productF).join(); - 最后逐个取值（此时已确定完成，
join()不会阻塞）：User u = userF.join(); Order o = orderF.join(); Product p = productF.join();
每个 Future 都要 handle 或 exceptionally 兜底
allOf 对异常完全静默：哪怕一个服务 500 或超时，allOf 仍可能正常返回；真正抛异常是在你调 xxx.join() 的那一刻——容易造成“响应空、日志无、监控平”的三无故障。
- 每个调用建议用
handle()统一处理成功与异常路径：CompletableFuture.supplyAsync(() -> api.call(), ioExecutor)<br> .handle((res, ex) -> ex != null ? fallbackUser() : res);
- 若需区分失败类型（如熔断 vs 超时），可用
completeOnTimeout(fallback, 2, SECONDS)+orTimeout(2, SECONDS)组合 - 聚合阶段检查 null 值，避免 NPE：
if (u == null || o == null || p == null) { return buildPartialResponse(u, o, p); }
聚合响应体建议封装成不可变 DTO，按需裁剪字段
网关层不传全量数据。用户详情里可能只取头像、昵称、会员等级；订单里只要状态和金额；商品只拿名称、价格、库存标识。
- 避免把
UserEntity、OrderDO直接塞进响应体，定义轻量级GatewayUserVO、GatewayOrderVO - 字段裁剪能减少序列化开销、网络传输耗时、前端解析压力，实测可降低 20%+ RT
- 若部分服务降级返回默认值，VO 中对应字段应有明确语义标识，比如
"user_status": "fallback"
