Spring WebFlux控制器应返回Mono<T>还是未包装的T？

结论先行：在Spring WebFlux响应式应用中，控制器返回Mono<T>或Flux<T>才是符合非阻塞I/O的最佳实践，绝对不要通过阻塞方式返回原始对象T。

为什么不能阻塞返回T？ #

• 破坏非阻塞核心：Spring WebFlux的设计初衷就是基于非阻塞I/O实现高并发、低资源消耗。如果在服务层或控制器调用block()解包Mono，会强制当前线程等待结果，线程被长时间占用，直接废掉响应式架构的优势。
• 违背响应式设计：响应式编程的核心是通过Mono/Flux传递异步数据流，全程保持异步非阻塞。阻塞操作会打破这个调用链的异步性，导致整个链路退化为传统的阻塞式处理。

为什么返回Mono才是正确选择？ #

• Spring WebFlux原生支持：框架完全适配响应式类型，当控制器返回Mono<MyResponseDto>时，会自动订阅这个Mono，在数据异步就绪后，自动序列化为JSON返回给客户端，全程不会阻塞线程。
• 保留异步编排能力：服务层返回Mono<T>可以保留Reactor的各种操作符能力（比如重试、超时、合并、转换等），控制器直接返回这个Mono，不会丢失这些异步逻辑的上下文。
• 符合整洁架构原则：服务层专注于业务逻辑的异步编排，控制器只负责请求路由和响应返回，两者职责清晰，符合单一职责原则。

纠正误区 #

你听到的“不在控制器返回Mono”是错误的，属于对响应式架构的误解。响应式应用的整个调用链都应该保持异步非阻塞，Mono/Flux就是传递异步结果的标准载体。

你的现有代码完全符合最佳实践，不需要修改：

@GetMapping("/example")
public Mono<MyResponseDto> getExample() {
    return myService.getData(); // returns Mono<MyResponseDto>
}

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