本文介绍如何在 project reactor 中优雅处理 mono.zip 操作中各源的独立错误，通过封装异常为可计算状态，实现“只要任一源成功即返回有效结果”的容错语义。
本文介绍如何在 project reactor 中优雅处理 mono.zip 操作中各源的独立错误，通过封装异常为可计算状态，实现“只要任一源成功即返回有效结果”的容错语义。
在使用 Mono.zip 组合多个异步操作时，默认行为是“短路失败”：任意一个源（如 funA()、funB() 或 funC()）发出错误信号，整个 zip 就立即终止，并将首个错误传播出去，其余未完成的源也会被取消。这种行为虽高效，但不满足需要聚合部分成功结果的业务场景——例如：当三个服务调用中仅 A 失败、B 和 C 成功时，仍应返回 B 和 C 的结果；仅当全部失败时才整体报错。
幸运的是，Project Reactor 提供了灵活的错误控制能力。核心思路是：将每个 Mono
以下是一个生产就绪的实现方案：
✅ 步骤 1：定义泛型结果包装器
public class ResultWrapper<t> {
private final T result;
private final Throwable error;
private ResultWrapper(T result) {
this.result = result;
this.error = null;
}
private ResultWrapper(Throwable error) {
this.result = null;
this.error = Objects.requireNonNull(error);
}
public static <t> ResultWrapper<t> success(T value) {
return new ResultWrapper(value);
}
public static <t> ResultWrapper<t> failure(Throwable error) {
return new ResultWrapper(error);
}
public Optional<t> getResult() {
return Optional.ofNullable(result);
}
public Optional<throwable> getError() {
return Optional.ofNullable(error);
}
}</throwable></t></t></t></t></t></t>
该类使用 Optional 安全暴露结果或异常，避免空指针，语义更清晰。
✅ 步骤 2：封装每个 Mono，统一错误为成功信号
private <t> Mono<resultwrapper>> wrapWithResult(Mono<t> source) {
return source
.map(ResultWrapper::success)
.onErrorResume(error -> Mono.just(ResultWrapper.failure(error)));
}</t></resultwrapper></t>
onErrorResume 确保无论 source 抛出何种异常，都转为一个携带 Throwable 的 ResultWrapper 并继续流式处理，从而“消除”错误信号对下游的影响。
✅ 步骤 3：组合并解析结果
Mono<tuple3>, ResultWrapper<b>, ResultWrapper<c>>> zipped =
Mono.zip(
wrapWithResult(funA()),
wrapWithResult(funB()),
wrapWithResult(funC())
);
Mono<apiresponse> response = zipped.flatMap(tuple -> {
ResultWrapper<a> a = tuple.getT1();
ResultWrapper<b> b = tuple.getT2();
ResultWrapper<c> c = tuple.getT3();
List<string> errors = new ArrayList();
List<object> successes = new ArrayList();
a.getError().ifPresent(e -> errors.add("A: " + e.getMessage()));
b.getError().ifPresent(e -> errors.add("B: " + e.getMessage()));
c.getError().ifPresent(e -> errors.add("C: " + e.getMessage()));
a.getResult().ifPresent(successes::add);
b.getResult().ifPresent(successes::add);
c.getResult().ifPresent(successes::add);
// 业务规则：全部失败才返回 error；否则返回成功数据（含部分失败提示）
if (successes.isEmpty()) {
return Mono.error(new RuntimeException("All sources failed: " + String.join("; ", errors)));
} else {
return Mono.just(new ApiResponse(successes, errors));
}
});</object></string></c></b></a></apiresponse></c></b></tuple3>
? 关键说明：此处无需 zipDelayError —— 因为 wrapWithResult 已确保每个源必然发出一个 ResultWrapper（成功或失败），因此普通 zip 即可等待全部完成。若原始源存在超时/取消风险，建议额外添加 .timeout(...) 或 .onErrorResume 做兜底。
⚠️ 注意事项
- 资源清理：若 funA/B/C 涉及数据库连接、HTTP 客户端等有状态资源，请确保其内部已做超时与异常恢复（如 WebClient 的 timeout()），避免 onErrorResume 掩盖资源泄漏。
- 异常分类：生产环境建议区分 BusinessException 与 SystemException，对前者可降级返回默认值，后者则需记录告警。
- 性能考量：wrapWithResult 引入轻微对象分配开销，但在绝大多数微服务场景下可忽略；如极端性能敏感，可考虑复用 ResultWrapper 实例（需注意线程安全）。
- 替代方案：对于更复杂的编排逻辑（如动态源数量、条件跳过），可结合 Flux.fromArray(...).flatMap(...).collectList() 实现更灵活的聚合。
通过上述模式，你不仅能实现“部分成功即响应”的弹性语义，还为后续扩展（如熔断统计、灰度标记、链路追踪上下文透传）打下了清晰的结构基础。真正的响应式韧性，始于对错误的第一手建模能力。
