本文详解如何在 Spring WebFlux/Reactor 环境中安全地顺序执行两个 Mono（如先发事件再查数据并保存），彻底规避 block() 导致的线程阻塞异常。

本文详解如何在 spring webflux/reactor 环境中安全地顺序执行两个 mono（如先发事件再查数据并保存），彻底规避 `block()` 导致的线程阻塞异常。

在响应式编程中，Mono 代表零或一个异步结果，其核心设计原则是非阻塞、声明式链式编排。当需要按序执行两个 Mono（例如：先调用 messageEvent() 发送事件，成功后再调用 getPersonById() 获取数据并持久化），错误做法是使用 .block() 强制同步等待——这会直接违反 Reactor 的调度模型，导致在 reactor-http-nio-* 这类 I/O 线程中抛出 IllegalStateException: block() is not supported 异常。

正确的解决方案是利用 Mono.then(Mono) 操作符：它忽略上游 Mono 的元素（仅监听完成信号），并在其成功终止后无缝订阅并返回下游 Mono。该操作符天然保持响应式链路完整，不引入任何阻塞，且线程上下文自动延续（默认由上游 Scheduler 决定）。

以下为推荐实现：

return spi.messageEvent(message)
    .then(spi.getPersonById(evt.getVictimId())) // ✅ 仅在 messageEvent 完成后触发 getPersonById
    .flatMap(victim -> repository.save(victim)); // ✅ 使用 flatMap 处理 save 返回的 Mono<victim></victim>

⚠️ 注意事项：

• 勿用 map(repository::save)：repository.save(...) 通常返回 Mono，而 map 期望同步函数（返回普通对象），会导致类型不匹配或隐式阻塞风险；应使用 flatMap 实现 Mono → Mono 的扁平化转换。
• 避免嵌套 doOnSuccess + block()：不仅阻塞线程，还会破坏背压与错误传播机制，使异常难以追踪。
• 确保所有下游操作均为响应式：包括数据库访问（如 Spring Data R2DBC）、HTTP 调用（WebClient）等，否则需通过 publishOn(Schedulers.boundedElastic()) 切换至弹性线程池（仅限真正无法响应式的遗留阻塞调用）。
• 错误处理建议：添加 .onErrorResume() 或 .doOnError() 显式处理各环节失败，例如：

  .then(spi.getPersonById(evt.getVictimId()))
  .flatMap(repository::save)
  .onErrorResume(e -> {
      log.error("Failed to process event for victim {}", evt.getVictimId(), e);
      return Mono.empty(); // 或返回兜底 Mono
  });

总结：Reactor 的力量在于“描述行为”而非“控制流程”。用 then() 表达“前一个完成后执行下一个”，用 flatMap() 表达“对上游结果异步转换”，全程无阻塞、可组合、可观测——这才是构建高吞吐、低延迟响应式服务的正确范式。