Spring Cloud Gateway Post过滤器WebClient顺序代理传参异常求助

核心问题根因 #

之前实现时序错乱的核心原因有三个：

• 对Reactor的Mono链组合语义理解偏差：chain.filter(exchange).then(Mono.fromRunnable{...})只会等待chain.filter(exchange)本身的同步执行完成，以及Runnable块的同步代码执行完成，不会感知Runnable块内部触发的WebClient异步请求状态。WebClient的请求是异步非阻塞的，从Runnable触发后会被调度到独立的线程池执行，整个Mono链不会等待这些异步请求的响应回来就直接走到下一个节点，自然会出现属性缓存为空、请求体不合法的问题。
• 后置阶段的请求构建没有遵循异步链式传递规则：所有带依赖关系的WebClient请求如果提前在同步代码块里完成构建，就会出现前序请求的响应还没写入缓存、后序请求已经提前读取参数的时序错位。
• 前置阶段的逻辑之所以运行正常，本质是把WebClient调用串在了chain.filter(exchange)之前的Mono操作链上，天然遵循异步等待的时序规则，没有把异步逻辑嵌套在无返回值的Runnable块里，所以属性传递链路是通顺的。

可行实现路径 #

1. 重构后置逻辑的Mono链组合方式 #

完全抛弃在Mono.fromRunnable中嵌套WebClient调用的写法，将每一步带数据依赖的后置代理逻辑，通过Mono.defer嵌套在主链路的后续操作链上，保证每一步只有在前一步的WebClient请求完全拿到响应、写入缓存之后，才会构建和执行下一个请求。
参考实现代码：

@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    // 先开启主请求的响应体缓存，避免后置阶段读不到一次性的响应流
    return ServerWebExchangeUtils.cacheResponseBody(exchange)
        .flatMap(cachedExchange -> 
            // 先执行主请求的路由转发，等待主请求完全完成后再进入后置逻辑
            chain.filter(cachedExchange)
                // 主链路完成后，执行第一个后置代理请求
                .then(Mono.defer(() -> {
                    // 从exchange缓存中读取入参，构建第一个后置请求
                    Object firstReqParam = cachedExchange.getAttribute("pre_cached_param");
                    return webClient.post()
                        .uri("http://downstream-service-a")
                        .bodyValue(firstReqParam)
                        .retrieve()
                        .bodyToMono(String.class)
                        .doOnNext(respA -> {
                            // 收到响应后立刻写入缓存，供下一个请求使用
                            cachedExchange.getAttributes().put("post_resp_a", respA);
                        });
                }))
                // 第一个后置请求完全完成后，执行第二个后置代理请求
                .then(Mono.defer(() -> {
                    // 读取上一步写入的缓存值，作为第二个请求的入参
                    String secondReqParam = cachedExchange.getAttribute("post_resp_a");
                    return webClient.post()
                        .uri("http://downstream-service-b")
                        .bodyValue(secondReqParam)
                        .retrieve()
                        .bodyToMono(String.class)
                        .doOnNext(respB -> {
                            cachedExchange.getAttributes().put("post_resp_b", respB);
                        });
                }))
                // 所有后置代理执行完成后，加工最终返回给客户端的响应
                .then(Mono.fromRunnable(() -> {
                    String finalRespContent = cachedExchange.getAttribute("post_resp_b");
                    ServerHttpResponse response = cachedExchange.getResponse();
                    response.writeWith(Mono.just(
                        response.bufferFactory().wrap(finalRespContent.getBytes(StandardCharsets.UTF_8))
                    ));
                }))
        );
}

2. 必须规避的常见实现坑 #

• 禁止在WebFlux事件循环线程中调用block()同步等待WebClient响应：这种操作会直接触发调度器的异常，打乱Gateway的非阻塞时序，所有等待逻辑都要通过Reactor的链式操作完成。
• 禁止提前在同步代码块中读取exchange的缓存属性：缓存值是在异步回调中写入的，提前读取拿到的永远是空值，所有参数读取操作必须放在对应依赖请求完成后的defer块内部执行。
• 不要把WebClient的请求实例提前初始化好固定入参：因为入参是动态从缓存读取的，必须等前序请求的响应落盘后，再构建请求的body、uri等参数，避免出现入参固化的问题。

调试验证技巧 #

在每一步WebClient请求的前后加日志，日志打印的顺序如果符合以下规则，就说明时序符合预期：

1. 主请求转发完成
2. 第一个后置请求发起，拿到响应
3. 第二个后置请求发起，拿到响应
   如果出现第二个请求的发起日志在第一个请求的响应日志之前，说明Mono链的组合方式有问题，没有等待前序请求完成。

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