Spring WebFlux中Mono运行机制及返回为接口响应时服务端处理流程

你给出的示例接口返回Mono<Product>类型的完整服务端处理流程如下，先贴示例代码：

@PostMapping("/product")
@ResponseStatus(HttpStatus.CREATED)
public Mono<Product> createProduct(@RequestBody Product product){
    return productService.save(product);
}

核心处理流程 #

1. 请求匹配与参数解析阶段 #

• 客户端发送POST /product请求后，WebFlux核心分发组件DispatcherHandler会匹配到对应的createProduct处理方法
• 框架自动异步读取完整请求体字节流，反序列化为Product参数对象，整个过程不会阻塞容器IO线程

2. 响应式流构建阶段 #

• 调用createProduct方法时，productService.save(product)不会立刻执行实际的保存逻辑，只会返回一个未订阅的Mono<Product>对象，这个对象本质是对「异步保存Product、最终返回1个Product结果」这一操作的描述，没有订阅就不会触发实际执行。

3. 订阅与业务逻辑执行阶段 #

• DispatcherHandler拿到返回的Mono<Product>后，会交给响应式返回值处理器进行处理，由处理器对这个Mono发起订阅
• 订阅动作触发后，productService.save(product)定义的实际业务逻辑才会真正执行（比如写入数据库、调用下游服务等），执行过程全程异步非阻塞，线程调度由Reactor和框架底层自动管理，无需手动干预。

4. 响应生成与返回阶段 #

• 当Mono正常发出结果元素：框架自动将Product对象序列化为JSON，写入HTTP响应体，同时按@ResponseStatus注解设置响应状态码为201，返回给客户端
• 当Mono执行抛出异常：触发WebFlux异常处理机制，匹配对应的异常处理器返回错误响应
• 当Mono为空无返回元素：默认返回200空响应，可通过自定义配置调整为空时的返回规则。

关键注意点 #

不要在接口逻辑中主动调用Mono.block()方法，会强制阻塞IO线程，直接抵消WebFlux异步非阻塞的性能优势。

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