嵌套Mono场景下flatMap与block的使用存在哪些差异？

你提到的「flatMap与block最终都会触发subscribe动作」的认知是正确的，但二者的订阅触发逻辑、后续执行行为存在本质区别，两段代码的执行逻辑差异非常大。

代码行为拆解 #

第一段代码 #

Mono.just("a").flatMap(value -> Mono.just("b")).subscribe();

flatMap是Reactor原生的非阻塞编排操作符，核心行为如下：

• 上游Mono.just("a")发出元素"a"后，框架自动将元素传入lambda生成内部Mono.just("b")
• 框架自动订阅这个内部Mono，整个订阅过程完全非阻塞，内部Mono的执行复用当前流的调度线程
• 内部Mono的执行结果、异常都会直接传递到主链下游，主链最终输出的元素是内部Mono发出的"b"
• 内部Mono的生命周期完全和主链绑定，内部Mono未完成时主链也不会结束

第二段代码 #

Mono.just("a").doOnNext(value -> Mono.just("b").block()).subscribe();

doOnNext是纯副作用操作符，搭配block()的核心行为如下：

• 上游Mono.just("a")发出元素"a"后，在当前线程同步执行lambda内部逻辑
• 你主动调用block()触发内部Mono的订阅，这个动作会阻塞当前线程，直到内部Mono执行完成才会继续往下走
• 内部Mono的执行结果、异常都不会传递到主链下游，主链最终输出的元素还是原来的"a"
• 内部Mono的生命周期和主链无关，就算内部Mono执行异常，若你没有在lambda内部捕获，会直接抛出同步异常终止主链执行

核心差异对比 #

• 线程模型差异：第一段全程非阻塞，符合响应式设计规范，调度资源由框架统一管控；第二段存在显式阻塞，高并发场景下极易占满调度线程池触发线程饥饿。
• 数据流向差异：第一段flatMap会替换主流的输出元素为内部Publisher的结果；第二段doOnNext不会修改主流传递的元素，内部Publisher的结果默认会被丢弃。
• 异常处理差异：第一段内部Publisher抛出的异常属于响应式流异常，可以通过主链的onError系列操作符统一处理；第二段block()抛出的异常属于同步异常，无法直接通过主链的异常处理算子捕获，必须在doOnNext内部手动try-catch。
• 背压支持差异：第一段内部Publisher的执行会参与全链路的背压管控；第二段block()完全绕过了背压机制，可能引发流量超过系统负载的问题。

内容的提问来源于stack exchange，提问作者Sergey Bespalov