在 spring webflux 应用中，当控制器方法接收 `mono` 作为请求体时，直接在响应式链中访问原始请求对象 `t` 可能会遇到挑战。本文将探讨一种更简洁高效的策略：通过将 `@requestbody` 参数类型从 `mono` 调整为 `t`，并在控制器内部使用 `mono.just(t)` 启动响应式流。这种方法不仅简化了代码，使原始请求数据在整个链中易于访问，而且避免了复杂的上下文管理，提升了开发效率和代码可读性。

Spring WebFlux 中 @RequestBody 的处理机制

在 Spring WebFlux 中，@RequestBody 注解用于将 HTTP 请求体绑定到方法参数。WebFlux 提供了多种方式来处理请求体，每种方式都有其特定的行为和适用场景：

1. 直接对象类型 (T): 例如 MyRequest myRequest。在这种情况下，WebFlux 会在控制器方法被调用之前完成请求体的反序列化。这意味着当控制器方法执行时，myRequest 对象已经完全可用，并且是阻塞式地（但对于 WebFlux 内部处理是非阻塞的）准备好的。
2. 响应式类型 (Mono): 例如 Mono myRequestMono。在这种情况下，控制器方法会立即接收到一个 Mono 对象。这个 Mono 代表了请求体在未来某个时间点被反序列化完成并发出 MyRequest 对象的信号。控制器可以利用这个 Mono 来声明在请求体反序列化完成后需要执行的逻辑。
3. 响应式流类型 (Flux): 例如 Flux myRequestsFlux。这通常用于处理输入流场景，当请求体包含多个对象并以流的形式到达时。

原始问题与挑战

考虑以下 Spring WebFlux 控制器方法：

@PostMapping("url")
public Mono<MyResponse> getMyResponse(@RequestBody Mono<MyRequest> myRequestMono) {
    return urlService.getUrl(myRequestMono)
            .doOnNext(url -> {
                // 在这里，如果想访问 myRequestMono 中原始的 MyRequest 对象，会比较困难
                System.out.println("Generated URL: Successfully ");
            })
            .map(dto -> MyResponse.builder().url(dto).build())
            .doOnError(e -> System.out.println("Error occurred " + e));
}

以及相应的服务层方法：

public Mono<String> getUrl(Mono<MyRequest> myRequestMono) {
    return myRequestMono.map(myRequest -> {
        // 在这里可以访问 myRequest 对象
        callSomething(myRequest);
        return "something";
    });
}

开发者面临的挑战是，如何在 doOnNext 等操作符中，直接访问到原始的 MyRequest 对象，例如为了日志记录其中的某个字段。虽然可以尝试使用 transformDeferredContextual 来将请求对象放入 Reactor Context 中，但这通常会增加不必要的复杂性，并且在某些情况下可能无法如预期般工作，因为它主要用于传递横切关注点或不属于数据流本身的信息。

推荐的解决方案

对于需要直接访问请求体内容的场景，更简洁且符合 WebFlux 设计理念的方法是利用 @RequestBody 对直接对象类型的支持。

核心思路：

Reactivation Specialist · 流失召回

适用于用户提出以下需求时：“构建赢回活动（win-back campaign）”、“重新激活已流失订阅者（re-engage lapsed subscribers）”、“执行重新授权 / 重新同意（re-permission / re-consent）清理”或“清理无效联系人列表（sunset my dead list）”；输出一个闭环式再激活方案——包括：流失用户群组（lapsed-cohort）定义、分阶段优惠阶梯（staged offer ladder）、重新授权（re-consent / re-p

下载

1. 将控制器方法中的 @RequestBody 参数类型从 Mono 更改为 MyRequest。
2. 在控制器方法内部，使用 Mono.just(myRequest) 将已反序列化的 MyRequest 对象包装成 Mono，从而启动响应式链。

这样，myRequest 对象在控制器方法内部就已经是完全可用的，并且可以作为局部变量在整个响应式链中被直接引用。

修改后的代码示例：

import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
import reactor.core.publisher.Mono;

@RestController
public class MyController {

    private final UrlService urlService; // 假设 UrlService 已注入

    public MyController(UrlService urlService) {
        this.urlService = urlService;
    }

    @PostMapping("/url")
    public Mono<MyResponse> getMyResponse(@RequestBody MyRequest myRequest) { // ① 更改参数类型为 MyRequest
        // ② 使用 Mono.just(myRequest) 启动响应式链
        return Mono.just(myRequest)
                .flatMap(req -> urlService.getUrl(Mono.just(req))) // 或者直接修改 service 方法接收 MyRequest
                .doOnNext(url -> {
                    // ③ 在这里可以直接访问 myRequest 对象及其字段
                    System.out.println("Generated URL: Successfully for request ID: " + myRequest.getRequestId());
                })
                .map(dto -> MyResponse.builder().url(dto).build())
                .doOnError(e -> System.out.println("Error occurred " + e));
    }
}

为了使上述控制器与服务层更好地配合，服务层方法也可以相应调整，直接接收 MyRequest 对象：

import reactor.core.publisher.Mono;

// 假设 MyRequest, MyResponse 类已定义
class MyRequest {
    private String requestId;
    // ... 其他字段和 getter/setter
    public String getRequestId() { return requestId; }
    public void setRequestId(String requestId) { this.requestId = requestId; }
}

class MyResponse {
    private String url;
    // ... 其他字段和 builder
    public static MyResponseBuilder builder() { return new MyResponseBuilder(); }
    public static class MyResponseBuilder {
        private String url;
        public MyResponseBuilder url(String url) { this.url = url; return this; }
        public MyResponse build() {
            MyResponse response = new MyResponse();
            response.url = this.url;
            return response;
        }
    }
}

// 假设 UrlService
class UrlService {
    public Mono<String> getUrl(MyRequest myRequest) { // ④ 服务层直接接收 MyRequest
        return Mono.fromCallable(() -> {
            // 在这里可以访问 myRequest 对象
            System.out.println("Processing request in service: " + myRequest.getRequestId());
            // 模拟一些耗时操作
            Thread.sleep(100);
            return "http://example.com/generated/" + myRequest.getRequestId();
        });
    }
}

控制器调用服务层的优化：

如果服务层方法也修改为直接接收 MyRequest，那么控制器中的 flatMap 可以简化：

@PostMapping("/url")
public Mono<MyResponse> getMyResponse(@RequestBody MyRequest myRequest) {
    return urlService.getUrl(myRequest) // 直接传递 myRequest 对象
            .doOnNext(url -> {
                System.out.println("Generated URL: Successfully for request ID: " + myRequest.getRequestId());
            })
            .map(dto -> MyResponse.builder().url(dto).build())
            .doOnError(e -> System.out.println("Error occurred " + e));
}

优点与注意事项

• 简洁性与可读性： 这种方法消除了在响应式链中传递原始请求对象时的复杂性，代码更直观易懂。
• 直接访问： myRequest 对象在控制器方法内部作为局部变量，可以在任何后续的 lambda 表达式中直接捕获和使用，无需额外的上下文管理。
• 性能考量： WebFlux 在将 MyRequest 直接反序列化到控制器参数时，其内部处理是非阻塞的。虽然从开发者的角度看，MyRequest 是在方法调用时“准备好”的，但这并不会引入阻塞的 I/O 操作。
• 何时仍使用 Mono 作为 @RequestBody？
  • 当控制器方法本身需要执行一些复杂的、依赖于请求体完全解析后才能进行的异步操作，并且这些操作需要利用 Mono 的特性（如合并、并行处理等）时。
  • 在某些高级流处理场景中，例如，你可能希望在请求体完全被读取之前，就开始响应式地处理请求头或其他信息。
  • 但对于简单的日志记录或在链中访问请求体字段的需求，直接使用 T 类型通常是更好的选择。

总结

在 Spring WebFlux 控制器中，为了方便地在响应式链的后续操作符（如 doOnNext）中访问原始的请求体对象，推荐将 @RequestBody 参数类型定义为直接对象类型（例如 MyRequest），而非 Mono。这样，WebFlux 会在控制器方法被调用前完成请求体的反序列化，使 MyRequest 对象在方法体内直接可用。随后，可以通过 Mono.just(myRequest) 启动响应式流，并直接在链中的任何地方引用 myRequest 局部变量，从而实现简洁高效的请求数据访问。这种方法避免了复杂的 Reactor Context 管理，提升了代码的可读性和维护性。