现代Spring框架中同步HTTP请求的正确实现方案探讨——WebClient替代RestTemplate的最佳实践疑问

作为从RestTemplate转用WebClient的开发者，我完全理解你的纠结——一边是官方说WebClient是未来方向，一边又听说block()是“响应式坏味道”，到底同步场景该怎么处理？咱们一步步理清楚：

先明确Spring的官方态度 #

Spring把RestTemplate放进维护模式后，WebClient确实是唯一推荐的HTTP客户端，但它的核心设计是为响应式编程服务的。官方文档里的那段话其实已经说得很清楚：

有时你只能将部分代码迁移为响应式，需要在命令式代码中复用响应式序列。因此，若你需要阻塞直到Mono的值可用，可以使用Mono#block()方法，当触发onError事件时它会抛出异常。请注意，应尽可能优先采用端到端的响应式代码来避免这种做法，绝对禁止在其他响应式代码中间使用该方法，因为这可能导致整个响应式管道锁死。

划重点：block()不是不能用，而是不能乱用。

什么时候可以放心用block()？ #

1. 存量命令式代码的过渡场景：如果你正在把老的RestTemplate代码逐步改成WebClient，但整个服务还没改成响应式（比如控制器还是返回普通对象，不是Mono/Flux），那在命令式代码的边界处用block()是完全合理的——相当于把响应式的结果“桥接”到命令式上下文里。
2. 测试场景：写单元测试或者集成测试时，为了快速获取结果验证逻辑，用block()非常方便，不会有性能问题。

举个正确的例子：

// 老的命令式服务类，暂时还没改造成响应式
@Service
public class UserService {
    private final WebClient webClient;

    public UserService(WebClient.Builder webClientBuilder) {
        this.webClient = webClientBuilder.baseUrl("https://api.example.com").build();
    }

    // 同步方法，调用WebClient并阻塞获取结果
    public User getUserById(Long userId) {
        return webClient.get()
                .uri("/users/{id}", userId)
                .retrieve()
                .bodyToMono(User.class)
                .block(); // 这里用block()没问题，因为是在命令式方法的末尾
    }
}

绝对不能用block()的场景 #

响应式管道内部绝对禁止调用block()！比如在Flux/Mono的flatMap、map等操作符里调用block()，这会直接阻塞响应式框架的工作线程——而响应式框架的线程池通常是有限的（比如Reactor的默认线程池），一旦线程被阻塞耗尽，整个应用的响应式管道就会锁死，完全失去非阻塞的优势。

错误示例：

// 千万别这么写！
public Flux<User> getUsersByIds(Flux<Long> userIds) {
    return userIds.flatMap(userId -> {
        // 在flatMap（响应式操作符）里调用block()，会导致线程阻塞
        User user = webClient.get()
                .uri("/users/{id}", userId)
                .retrieve()
                .bodyToMono(User.class)
                .block();
        return Mono.just(user);
    });
}

有没有不用block()的同步方式？ #

很遗憾，没有。WebClient的所有HTTP调用方法返回的都是Mono/Flux，这是它的核心设计。要同步获取结果，必须通过阻塞等待响应式信号的方式——也就是block()。Spring并没有为WebClient提供类似RestTemplate的同步API，因为这违背了WebClient的响应式设计初衷。

长期的最佳实践是什么？ #

如果你的代码库打算长期维护，优先推进端到端的响应式改造：从控制器（返回Mono/Flux）到服务层（全响应式方法）再到HTTP调用（WebClient返回Mono/Flux），全程避免阻塞操作。这样才能真正发挥响应式框架的优势：非阻塞、高并发、资源高效。

如果暂时无法全量改造，block()作为过渡方案是完全可以接受的，但一定要严格控制使用范围——只在命令式代码的边界处使用，不要在响应式代码内部混用。

总结一下：block()不是“坏味道”，而是一个有明确适用场景的工具。用对地方，它是存量代码迁移的好帮手；用错地方，它会成为性能杀手。WebClient的设计意图确实是鼓励非阻塞编程，但也兼顾了现实的迁移需求——至于要不要全量改造成响应式，取决于你的项目长期规划和业务场景。

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