WebFlux 深度：Reactor 线程模型、背压与错误处理

概述

在掌握了 Spring MVC 的请求处理全链路和 REST 客户端之后，本文将视角转向 Spring 生态中彻底颠覆线程模型的 WebFlux 框架。WebFlux 放弃了传统的每请求一线程，拥抱响应式流和非阻塞 IO，从根本上解决了高并发下的线程资源瓶颈。它的核心是 Reactor 的事件循环、智能背压和延迟错误处理，这些机制使得 Web 应用能够以固定数量的线程应对数万并发连接。

Spring WebFlux 并非 Spring MVC 的简单替代，而是对 Web 编程模型的重新思考。当 Tomcat 线程池被占满时，请求只能排队等待；而在 WebFlux 的事件循环中，线程数量是固定的，请求的处理变成了廉价的异步事件触发。这种模型的转变带来了巨大的吞吐量潜力，但也引入了背压协调、错误信号传播和线程调度等新的复杂性。本文将深入 Reactor 的线程调度器，剖析 WebFlux 如何在 Netty 上实现端到端的非阻塞，并探讨如何控制数据流的速度，确保在响应式管道中平稳地处理错误。

核心要点

• 事件循环模型：WebFlux 基于 Netty 的 I/O 工作线程，不再为每个请求分配独立线程。
• Reactor 线程调度 ：Schedulers 的分类及其在 WebFlux 中的默认使用规则。
• 背压传播 ：下游消费速度如何向上游传递，以及如何利用 limitRate 等操作符进行流量整形。
• 响应式错误处理 ：onErrorResume、onErrorReturn 与全局错误 WebExceptionHandler。
• 阻塞边界检测：BlockHound 在开发期间的作用，以及调用阻塞 API 对事件循环的致命影响。

文章组织架构图

flowchart TD subgraph S1 ["基础认知"] n1["1. 响应式流与Reactor核心回顾"] n2["2. WebFlux线程模型：从Servlet线程池到事件循环"] end subgraph S2 ["核心机制"] n3["3. 背压：响应式管道的流量控制"] n4["4. 错误处理：从信号到HTTP错误响应"] end subgraph S3 ["工程落地"] n5["5. WebFlux的请求处理组件与过滤器"] n6["6. 阻塞检测与性能陷阱"] end subgraph S4 ["实践与总结"] n7["7. 生产事故排查专题"] n8["8. 面试高频专题"] end n1 --> n2 --> n3 --> n4 --> n5 --> n6 --> n7 --> n8 classDef default fill:#f8f9fa,stroke:#333,stroke-width:1px,color:#333; classDef subgraphTitle fill:#e9ecef,stroke:#adb5bd,stroke-width:2px,color:#333,rx:5; class S1,S2,S3,S4 subgraphTitle;

架构图说明

• 总览说明：全文 8 个模块遵循从理论到实践、从底层到应用的逻辑递进。首先建立响应式流和事件循环的认知基础，然后深入剖析背压和错误处理两大核心运行机制，接着聚焦于 WebFlux 框架的工程组件与性能陷阱，最后通过生产事故和面试题将知识转化为实践能力与应试技巧。
• 逐模块说明：模块 1-2 建立线程和事件循环的核心认知，是理解"为什么 WebFlux 能实现高并发"的关键。模块 3-4 剖析数据流控制与错误恢复，这是保证响应式应用健壮性的核心。模块 5-6 聚焦 WebFlux 特有的过滤和性能诊断工具，将机制落地到框架使用。模块 7-8 通过案例分析和面试准备，将理论知识转化为解决实际问题和应对技术面试的能力。
• 关键结论 ：WebFlux 的性能提升并非免费，严格遵循非阻塞原则和理解背压机制是避免生产灾难的前提。 开发人员必须从"命令式"的线程阻塞思维彻底转向"响应式"的事件驱动与信号传递思维。

---

1. 响应式流与 Reactor 核心回顾

在深入 WebFlux 之前，必须建立其语言基础------响应式流规范与 Reactor 实现。这是重构整个 Web 处理引擎的基石。

1.1 响应式流规范：Publisher、Subscriber、Subscription、Processor

响应式流是一个面向非阻塞背压的异步流处理标准。它由四个核心接口定义，分布在 Java 9 的 java.util.concurrent.Flow 中，但 Spring WebFlux 和 Reactor 3.x 基于 JDK 8，因此它们直接依赖 Reactor 项目中对规范的独立定义（org.reactivestreams 包）。

• Publisher<T> ：生产者。它只有一个方法 subscribe(Subscriber<? super T> s)，用于建立与下游 Subscriber 的连接。
• Subscriber<T> ：消费者。定义了四个生命周期方法：
  • onSubscribe(Subscription s)：订阅成功时被调用，接收到控制上下游通信的 Subscription 令牌。
  • onNext(T t)：接收到下一个数据元素。
  • onError(Throwable t)：接收到一个错误信号，流终止。
  • onComplete()：接收到完成信号，流终止。
• Subscription ：连接 Publisher 和 Subscriber 的桥梁，也是背压控制的关键。其核心方法是 request(long n)，下游通过调用它向上游发出需求信号"我能处理 n 个元素"；以及 cancel()，用于取消流并清理资源。
• Processor<T, R> ：同时实现了 Subscriber<T> 和 Publisher<R>，代表一个处理阶段，可位于流管道的中间。

这套规范的核心价值在于通过 Subscription.request(n) 实现了从下游到上游的动态背压机制，让慢速消费者能通知生产者降低速度，而不是被数据洪流淹没。

1.2 Reactor 的 Mono 与 Flux

Reactor 是响应式流规范的一个具体实现，是 Spring WebFlux 的响应式内核。它将一切都抽象为两种响应式类型。

• Mono<T>：代表一个异步的、产生 0 到 1 个结果的序列。例如，一个 HTTP 请求的异步响应、一个数据库查询的单条结果。
• Flux<T>：代表一个异步的、产生 0 到 N 个结果的序列。例如，一个流式查询结果、一个事件流、一个集合的迭代。

Mono 和 Flux 都是 Publisher 的实现，因此也遵循响应式流的协议。和 CompletableFuture 只能处理单个异步结果且不支持延迟和背压不同，使用 Mono/Flux 可以构建一个声明式的、惰性的数据处理管道，数据只有在被"订阅"时才开始流动。

1.3 从创建到订阅：一个完整的生命周期示例

下面是一个展示了从创建、操作到订阅的完整过程。

// 1. 创建一个 Flux 发布者，它作为数据源头
Flux<Integer> dataStream = Flux.range(1, 10)  // 产生1到10的整数
        .map(i -> {
            // 模拟一个可能抛出异常的处理
            if (i == 7) {
                throw new RuntimeException("数字7不受欢迎");
            }
            return i * 10;
        })
        .log(); // 日志记录所有反应式信号，便于观察

// 2. 订阅这个发布者
dataStream.subscribe(
        value -> System.out.println("接收到: " + value), // onNext 消费者
        error -> System.err.println("发生错误: " + error), // onError 消费者
        () -> System.out.println("处理完成!")             // onComplete 消费者
);

这个简单的示例揭示了几个关键点：

1. 惰性求值 ：在 subscribe 被调用前，Flux.range 和 .map 中没有任何代码被执行。流只是一个声明。
2. 信号驱动 ：流的执行和生命周期完全由 onSubscribe、onNext、onError、onComplete 这些信号来驱动。
3. 背压支持 ：在此例中，Flux.range 是一个支持背压的源。底层的订阅者会通过 request(n) 请求数据，range 会严格按照请求数量生产。我们在日志中能看到 request(unbounded) 或 request(n) 的记录。

在 WebFlux 的上下文中，框架充当了"终极订阅者"的角色，它负责将 Mono 或 Flux 产生的数据写入 HTTP 响应。理解了信号驱动的生命周期，是掌握 WebFlux 请求处理链路的第一步。

---

2. WebFlux 线程模型：从 Servlet 线程池到事件循环

WebFlux 最根本的变革在于其线程模型，这使得它能以少量固定线程支撑海量并发。

2.1 传统 Servlet 容器的"每请求一线程"模型

在传统的 Servlet 规范下，如 Tomcat，一个 HTTP 连接在其整个生命周期内，通常会占据一个 Worker 线程池中的一个线程。

sequenceDiagram actor Client as 客户端 participant Connector as HTTP 连接器 participant ThreadPool as 线程池 (200线程) participant Servlet as 业务Servlet Client->>+Connector: 发起请求 (连接1) Connector->>+ThreadPool: 分配线程 Thread-1 ThreadPool->>+Servlet: Thread-1 执行 service() Note over Thread-1, Servlet: 业务逻辑阻塞等待数据库/IO... Servlet-->>-ThreadPool: 返回响应 ThreadPool-->>-Connector: 释放线程 Thread-1 Connector-->>-Client: 响应 Note over ThreadPool: 当200个线程全被阻塞时，
新请求只能排队等待。

• 图表主旨概括：该图描绘了传统 Servlet 容器中线程与请求的1:1强绑定关系。
• 逐层/逐元素分解 ：客户端请求到达 Connector 后，由 ThreadPool 分配一个空闲线程去执行 Servlet。图中 Thread-1 在执行 service() 方法时被业务逻辑阻塞，在此期间它无法处理任何其他任务。该线程一直绑在这个连接上，直到响应返回才被释放。
• 设计原理映射 ：这是典型的同步阻塞 I/O 模型。因为它简单，易于理解、开发和调试，线程的调用栈保存了完整的执行上下文。但其致命缺陷是线程是一种昂贵资源，其数理极限直接决定了系统的并发连接上限。
• 工程联系与关键结论 ：在 Servlet 模型中，并发量 ≈ 线程池大小。这意味着为了支持更多并发，就必须增加更多线程，这会带来巨大的内存开销和上下文切换成本。这在 Servlet 3.1 引入异步支持后有所缓解，但底层模型依然没有脱离线程池的束缚。

2.2 WebFlux 的 Event Loop 模型

WebFlux 默认基于 Netty，一个异步事件驱动的网络应用框架。Netty 的核心是 Event Loop（事件循环） 模型。

sequenceDiagram actor Client1 as 客户端1 actor Client2 as 客户端2 participant NIOServer as NIO 服务器 (单线程 EventLoop示例) participant Pipeline1 as ChannelPipeline 1 participant Pipeline2 as ChannelPipeline 2 participant Application as 应用层 (Netty I/O 线程) Client1->>NIOServer: 建立连接 → Channel1 Client2->>NIOServer: 建立连接 → Channel2 NIOServer->>Application: 触发 Channel1 读事件 Application-->>Pipeline1: 读取数据，执行非阻塞处理 Application->>NIOServer: 返回，处理其他事件 NIOServer->>Application: 触发 Channel2 读事件 Application-->>Pipeline2: 读取数据，执行非阻塞处理 Application->>NIOServer: 返回 NIOServer->>Application: Channel1 下游数据就绪，写入响应 Application-->>NIOServer: 写入完成，返回 Note over Application: 线程始终忙碌但从不阻塞，
快速地在不同事件间切换。

• 图表主旨概括：该图对比了"每请求一线程"模型，展示了单个 Event Loop 线程如何通过非阻塞 IO 和事件循环处理海量连接。
• 逐层/逐元素分解 ：多个客户端连接 (Channel1, Channel2) 被注册在同一个 NIOServer（Event Loop）上。当任何一个 Channel 上有 I/O 事件（可读、可写）时，操作系统会通知，Event Loop 线程就会快速执行相应的 ChannelPipeline 中的逻辑。关键点在于，应用层的处理必须是非阻塞的，任务完成后线程立即返回，去处理下一个事件。
• 设计原理映射 ：这是异步非阻塞 I/O 模型和 Reactor 设计模式 的经典应用。它通过将阻塞的 I/O 操作交由操作系统和少数线程处理，让少量应用线程通过事件驱动来服务大量连接。CPU 核心的利用率被最大化。
• 工程联系与关键结论 ：WebFlux 的并发能力不再受限于线程数，而是受限于内存和网络带宽。 少数几个 Netty I/O 工作线程就能支撑成千上万个并发连接。但这种模型要求整个处理链路都不能有阻塞操作，否则一个阻塞就会让整个 Event Loop 停滞，导致服务雪崩。

2.3 Spring WebFlux 的异步运行时：Reactor Netty 与 HttpServer 适配

当 Spring Boot 2.x 启动一个 WebFlux 应用时，它实际上是启动了一个 Reactor Netty 的 HttpServer。这个 HttpServer 是 Netty 的响应式封装。

// Reactor Core && Reactor Netty 关键源码路径 (简化)
public class HttpServer {
    public static HttpServer create() { ... }

    // 配置处理器
    public HttpServer handle(BiFunction<? super HttpServerRequest, ? super HttpServerResponse, ? extends Publisher<Void>> handler) {
        // ...
    }

    // 绑定端口并返回一个 DisposableServer
    public final DisposableServer bindNow() {
        // ... 内部调用 TcpServer.bindNow()
    }
}

Spring 框架通过 ReactorHttpHandlerAdapter 将标准的 HTTP 处理接口 HttpHandler 适配到 Netty 的世界。

// org.springframework.http.server.reactive.ReactorHttpHandlerAdapter
public class ReactorHttpHandlerAdapter implements BiFunction<HttpServerRequest, HttpServerResponse, Publisher<Void>> {

    private final HttpHandler httpHandler;

    // ... 构造函数

    @Override
    public Publisher<Void> apply(HttpServerRequest reactorRequest, HttpServerResponse reactorResponse) {
        // 1. 将 Reactor Netty 的 request/response 适配成 Spring 的 ReactiveServerHttpRequest/Response
        NettyDataBufferFactory bufferFactory = new NettyDataBufferFactory(reactorResponse.alloc());
        ServerHttpRequest adaptedRequest = new ReactorServerHttpRequest(reactorRequest, bufferFactory);
        ServerHttpResponse adaptedResponse = new ReactorServerHttpResponse(reactorResponse, bufferFactory);
        // 2. 调用 Spring Web 层的入口点 HttpHandler
        return this.httpHandler.handle(adaptedRequest, adaptedResponse);
    }
}

解读 ：这个适配器实现了 BiFunction，是 Netty 世界和 Spring 世界连接的桥梁。它将 Netty 的非 HTTP 语义的请求和响应，转换为 Spring 定义的响应式 ServerHttpRequest 和 ServerHttpResponse，然后交给 HttpHandler 去处理。HttpHandler 是 Spring Web 层处理 HTTP 请求的最顶层的契约。

2.4 线程调度器：Schedulers 的分工

WebFlux 的核心原则是不阻塞 I/O 线程 。但现实中总存在无法避免的阻塞调用（如 JDBC），或者计算密集型任务。为此，Reactor 提供了 Schedulers 工具类，用于将任务调度到不同的线程池中执行。

• Schedulers.immediate()：在当前线程同步执行。
• Schedulers.single()：一个可复用的单线程。适合那些需要状态一致性的任务。
• Schedulers.parallel() ：一个固定大小的工作线程池，线程数默认与 CPU 核心数相同。专为计算密集型任务设计。
• Schedulers.boundedElastic() ：一个有界的、可弹性伸缩的线程池。这是处理阻塞 I/O 任务的"安全阀"。线程空闲一段时间后会被回收，且有线程数上限，防止因大量阻塞任务而耗尽资源。

WebFlux 中的默认行为与规范：

• Netty 的 I/O 工作线程 (Event Loop) 用于非阻塞的网络 I/O 和整个 WebFlux 的处理管道。无需，也不应在代码中显式调用 publishOn(Schedulers.parallel()) 来改变请求处理的主流程。
• 当你在 WebFlux 的控制器中返回一个 Mono 或 Flux 时，操作默认在 Netty 的 I/O 线程上执行。
• Schedulers.boundedElastic() 应当仅用于包裹阻塞调用。

// 示范：将阻塞的JDBC调用隔离到 boundedElastic 线程池
Mono<User> blockingWrapper = Mono.fromCallable(() -> {
    // 这是一个阻塞的 JDBC 调用
    return jdbcTemplate.queryForObject("SELECT * FROM user WHERE id = ?", userRowMapper, 1);
})
.subscribeOn(Schedulers.boundedElastic()); // 将整个订阅和阻塞调用隔离到专有线程池

// 后续处理又自动切回 Netty 的 Event Loop 线程
blockingWrapper.map(user -> {
    System.out.println("处理线程: " + Thread.currentThread().getName());
    return user;
});

关键点 ：subscribeOn 影响的是上游 源的运行线程。一旦数据进入管道，后续操作符如果没有被显式调度，会继续在 subscribeOn 指定的线程上执行。要让后续操作切回 I/O 线程，可以使用 publishOn(Schedulers.single())，但 WebFlux 的默认机制会保证在写入响应时回归到 Netty 的 I/O 线程，因此通常无需手动处理。

---

3. 背压：响应式管道的流量控制

背压是响应式系统区别于传统 Push 模型（如 Java Streams）的关键特性，也是避免 OutOfMemoryError 的基石。

3.1 背压的核心：Subscription.request(n)

背压的本质是一个从下游向上游反向传递的"需求"信号。

sequenceDiagram participant Publisher participant DataStream participant Subscriber Publisher->>Subscriber: onSubscribe(Subscription) Note over Subscriber: 我现在只想要3个元素 Subscriber->>Publisher: subscription.request(3) Publisher->>Subscriber: onNext(item-1) Publisher->>Subscriber: onNext(item-2) Publisher->>Subscriber: onNext(item-3) Note over Publisher: 暂停生产，等待下一个需求信号 Note over Subscriber: 我现在又能处理2个了 Subscriber->>Publisher: subscription.request(2) Publisher->>Subscriber: onNext(item-4) Publisher->>Subscriber: onNext(item-5)

• 图表主旨概括 ：该序列图清晰地展示了通过 Subscription.request(n) 实现下游控制上游生产速度的协议。
• 逐层/逐元素分解 ：
  1. onSubscribe：订阅建立时，生产者将 Subscription 令牌交付给消费者。
  2. request(3)：消费者根据自身处理能力，通过令牌请求首批 3 个元素。
  3. onNext × 3：生产者严格按照请求数量下发元素。
  4. request(2)：消费者处理完后，再次请求 2 个元素。这个过程重复直到流结束。
• 设计原理映射 ：这是一个经典的 Pull-Push 混合模型 。请求是 Pull 的（"我要 N 个"），但数据到达是 Push 的（onNext）。这保证了数据总是以消费者能承受的速度流动。
• 工程联系与关键结论 ：背压的基础是 Subscription.request(n) 信号能沿操作符链向上游传播。 绝大多数 Reactor 操作符（如 map, filter）是"透明传递"背压的。但某些操作符（如 flatMap， zip）因其内部逻辑，可能会改变需求信号的传导方式，开发者需要对此保持警惕。

3.2 Reactor 中的背压与操作符

• 透明操作符 ：map, filter, doOnNext 等操作符。当它的下游请求 n 个元素时，它会立刻向上游请求 n 个元素。
• flatMap 与 prefetch ：flatMap 会将一个元素映射为多个内部 Publisher。它无法准确预知一个外部元素会产生多少内部元素。因此，flatMap 有一个 prefetch 参数（默认 256），它会先向上游请求 prefetch 个元素，然后通过一个内部队列来协调多个内部流的背压。
• limitRate(n) ：这是一个用于上游发出的元素进行"微批"预取的操作符。下游的一次 request(n) 可能会被 limitRate 拆分成多批向上游请求，防止生产者一次性生产过多数据。

3.3 背压失控：MissingBackpressureException 与缓解策略

当上游是一个不支持背压的源（例如，一个不断产生事件的 Flux.create，但生产者忽略了了下游的信号），或者背压信号被中断时，就会发生问题。

// 一个不响应背压的生产者，可能导致 MissingBackpressureException
Flux<Long> source = Flux.create(emitter -> {
    // 模拟一直发送数据，完全忽略下游需求
    new Thread(() -> {
        long i = 0;
        while (true) {
            emitter.next(i++);
            try { Thread.sleep(10); } catch (Exception e) { }
        }
    }).start();
});

// 一个慢速消费者
source
    .doOnNext(i -> { /* 模拟慢速处理 */ })
    .subscribe();

// 运行一段时间后，会抛出 reactor.core.Exceptions$OverflowException，
// 其根本原因是 MissingBackpressureException

此时，需要通过以下操作符来提供背压缓冲或丢弃策略：

• onBackpressureBuffer(int maxSize, Consumer<? super T> onOverflow)：创建一个有界缓冲区。当上游生产速度超过下游消费时，数据先进入缓冲区；缓冲区满后，执行溢出策略（如丢弃、报错）。
• onBackpressureDrop(Consumer<? super T> onDropped)：当下游跟不上时，直接丢弃数据。可选择调用回调记录被丢弃的元素。
• onBackpressureLatest()：只保留上游发出的最新元素。当下游繁忙时，旧的元素会被新的覆盖。

source
    .onBackpressureBuffer(1000, dropped -> log.warn("背压溢出，丢弃: {}", dropped))
    .subscribe(/* slow consumer */);

3.4 WebFlux 中的背压体现

在 WebFlux 中，背压在多个层面起作用：

1. TCP 层：Netty 的 TCP 栈会自动管理 TCP 滑动窗口。如果应用层读取慢，操作系统接收缓冲区会变满，进而通知发送方减慢速度。这是最底层的背压。
2. 请求体读取 ：ServerHttpRequest.getBody() 返回的是一个 Flux<DataBuffer>。当 Web 过滤器或 Controller 在处理这个流时，通过 request(n) 信号影响着从网络套接字读取数据的速度，从而形成背压，防止整个请求体一下加载到内存。
3. 响应体写出 ：当返回一个大型 Flux 作为响应体（如 application/stream+json）时，WebFlux 的 writeWith 操作会将给定的 Publisher<DataBuffer> 写入 HTTP 响应。这里，Netty 的写入操作是异步的，只有当 Socket 缓冲区有空间时，它才会向上游的 Publisher 请求更多数据。如果客户端消费速度慢，服务器端的 Socket 写入就会变慢，从而自然地形成背压，使服务端的 Flux 生产速度降低。

---

4. 错误处理：从信号到 HTTP 错误响应

在响应式编程中，错误不再是通过 try-catch 块，而是作为一个终止信号 onError 在管道中传播。

4.1 Reactor 的错误信号与恢复操作符

一旦任何阶段抛出异常或发出 onError 信号，流就会立刻终止，并将错误信号向下游传递，直到被某个错误处理操作符捕获。

flowchart LR subgraph 管道 A[map: 正常处理] --> B[map: 发生异常] --> C[map: 不会执行] end B -- onError Signal --> D{onErrorResume?} C -.-> D D -- 捕获并返回备选流 --> E[备选 Publisher] D -- 未捕获 --> F[全局错误处理 / 中断] E --> G[继续 onNext/onComplete]

• 图表主旨概括 ：该图描绘了错误信号在响应式管道中的传播路径，以及 onErrorResume 等操作符如何拦截并恢复流。
• 逐层/逐元素分解 ：当 B 操作符发生异常，它后面的 C 不会执行。异常转换成 onError 信号向下游传播。当它到达 D 节点（如 onErrorResume）时，如果异常类型匹配，则切换到备选 Publisher E，流得以恢复。如果直到订阅者都没有匹配的操作符，错误就会到达 Subscriber.onError，流彻底中断。
• 设计原理映射 ：这是典型的 AOP（面向切面）思想在响应式流中的体现。错误处理逻辑与正常业务逻辑分离，可以将错误恢复、降级等横切关注点集中管理。
• 工程联系与关键结论 ：onErrorResume 是响应式编程中最强大的恢复工具 ，它不仅捕获错误，还能动态替换为另一个备选流，实现优雅降级。这与 Spring MVC 的 @ExceptionHandler 返回一个视图或错误信息在本质上类似，但在 Reactor 中，它发生在流内部。

核心错误处理操作符：

• onErrorReturn(T fallbackValue)：遇到任何错误，返回一个静态默认值，流正常完成。
• onErrorResume(Function<Throwable, ? extends Publisher<T>> fallback) ：遇到错误，执行一个函数，该函数可以分析异常并返回一个全新的 Publisher（例如调用另一个服务获取降级数据），实现动态恢复。
• onErrorMap(Function<Throwable, ? extends Throwable> mapper)：转换错误。用于将底层异常包装为更上层的业务异常。
• retry(long n) ：简单地重试 n 次，再次订阅同一个源。
• retryWhen(Retry maxRetries)：更精细的重试控制，支持指数退避等复杂策略。

4.2 WebFlux 的全局错误处理

当管道中的错误信号没有被处理，最终会冒泡到 WebFlux 框架层。

注解模式 ：和 MVC 一样，可以使用 @ExceptionHandler 注解在 @ControllerAdvice 或 @RestControllerAdvice 类中。但其方法签名必须返回 Mono<ResponseEntity<?>>，保持响应式语义。

函数式模式 ：函数式路由通过 WebExceptionHandler 接口实现全局异常处理。

// org.springframework.web.server.WebExceptionHandler
public interface WebExceptionHandler {
    Mono<Void> handle(ServerWebExchange exchange, Throwable ex);
}

Spring 提供了一个默认实现 DefaultErrorWebExceptionHandler，它会将错误映射为标准的 HTTP 错误状态，并根据请求的 Accept 头返回 JSON 或 HTML。自定义时，推荐继承 AbstractErrorWebExceptionHandler，它能让你轻松地定制路由、错误属性、渲染格式等。

@Component
@Order(-2) // 优先级高于 DefaultErrorWebExceptionHandler
public class CustomErrorWebExceptionHandler extends AbstractErrorWebExceptionHandler {

    public CustomErrorWebExceptionHandler(ErrorAttributes errorAttributes,
                                          ApplicationContext applicationContext,
                                          ServerCodecConfigurer codecConfigurer) {
        super(errorAttributes, new ResourceProperties(), applicationContext);
        super.setMessageWriters(codecConfigurer.getWriters()); // 注入消息转换器
        super.setMessageReaders(codecConfigurer.getReaders());
    }

    @Override
    protected RouterFunction<ServerResponse> getRoutingFunction(ErrorAttributes errorAttributes) {
        return RouterFunctions.route(RequestPredicates.all(), this::renderErrorResponse);
    }

    private Mono<ServerResponse> renderErrorResponse(ServerRequest request) {
        Map<String, Object> errorPropertiesMap = getErrorAttributes(request, ErrorAttributeOptions.defaults());
        return ServerResponse.status((Integer) errorPropertiesMap.get("status"))
                .contentType(MediaType.APPLICATION_JSON)
                .body(BodyInserters.fromValue(errorPropertiesMap));
    }
}

关键点 ：@Order(-2) 确保它能优先生效。AbstractErrorWebExceptionHandler 本身实现了一个 RouterFunction，将所有未处理的异常请求路由到 renderErrorResponse 方法，从而构建一个统一的 JSON 错误响应。

---

5. WebFlux 的请求处理组件与过滤器

WebFlux 构建了一套与 Servlet 完全不同的请求处理链，但同样支持强大的扩展点。

5.1 WebFilter 链 vs HandlerInterceptor

这是 WebFlux 与 MVC 过滤器机制的核心差异所在。

sequenceDiagram participant Client participant Netty EventLoop participant WebFilterChain participant WebFilter1 participant WebFilter2 participant Handler (Router/Controller) Client->>+Netty EventLoop: HTTP Request Netty EventLoop->>+WebFilterChain: activate WebFilterChain->>+WebFilter1: filter(exchange, chain) WebFilter1->>+WebFilter2: chain.filter(exchange) (执行下一个) Note over WebFilter1: 请求预处理逻辑... WebFilter2->>+Handler: chain.filter(exchange) Note over WebFilter2: 请求预处理逻辑... Handler-->>-WebFilter2: handle(request) 返回 MonoVoid Note over WebFilter2: 响应后处理逻辑... WebFilter2-->>-WebFilter1: 返回 MonoVoid Note over WebFilter1: 响应后处理逻辑... WebFilter1-->>-WebFilterChain: 返回 MonoVoid WebFilterChain-->>-Netty EventLoop: 返回 MonoVoid Netty EventLoop-->>-Client: HTTP Response (当 MonoVoid 完成时) Note over Handler: Handler 可能是 RouterFunction 定位的 HandlerFunction

• 图表主旨概括 ：该序列图表示了 WebFilter 链如何通过嵌套 Mono 的组装，实现请求的前置/后置处理。
• 逐层/逐元素分解 ：这是一个典型的职责链模式。每个 WebFilter 都接收 ServerWebExchange（封装了 request/response）和 WebFilterChain。关键的差异点是 chain.filter(exchange) 返回一个 Mono<Void>。过滤器的后置处理是通过在这个 Mono 上添加 doFinally, doOnSuccess 等操作符实现的。
• 设计原理映射 ：响应式 Mono 组装 。这与 HandlerInterceptor 的 preHandle/postHandle 分离的调用是截然不同的。WebFilter 的整个逻辑，包括前置和后置，都在同一个 filter 方法中声明式地构造成一个响应式链。
• 工程联系与关键结论 ：
  • HandlerInterceptor 是命令式的、同步的，其 postHandle 在 Controller 成功执行后调用。
  • WebFilter 是响应式的、异步的，其后置逻辑是基于 Mono 信号触发的。即使 Controller 返回的 Mono 还未完成（如一个异步的数据库写入），filter 方法本身已经返回了，真正后置逻辑会在 Mono 完成时执行。这使 WebFilter 天然能感知到异步处理的最终结果。

5.2 WebHttpHandlerBuilder 组装处理链

Spring WebFlux 并未使用 Servlet，它有自己的"处理器链"装配器。

// org.springframework.web.server.adapter.WebHttpHandlerBuilder
public class WebHttpHandlerBuilder {
    // ... 字段
    public static WebHttpHandlerBuilder applicationContext(ApplicationContext context) { ... }

    public WebHttpHandlerBuilder filters(Consumer<List<WebFilter>> consumer) { ... }
    // ... 其他方法

    public HttpHandler build() {
        // 1. 准备核心处理器：从Bean中查找 WebHandler 和 WebExceptionHandler
        WebHandler webHandler = this.webHandler != null ? this.webHandler : getWebHandler();
        // 2. 构建过滤器链：将多个 WebFilter 包装 WebHandler
        FilteringWebHandler filteringWebHandler = new FilteringWebHandler(webHandler, this.filters);
        // 3. 包裹异常处理器：用 ExceptionHandlingWebHandler 包装
        WebHandler exceptionHandler = new ExceptionHandlingWebHandler(filteringWebHandler, this.exceptionHandlers);
        // 4. 最终返回 HttpHandler 适配器
        return new HttpWebHandlerAdapter(exceptionHandler, ...);
    }
}

解读：

1. WebHandler ：核心的路由处理器。在 @EnableWebFlux 注解模式下，它最终代理给 DispatcherHandler，类似于 MVC 的 DispatcherServlet。在函数式模式下，它就是一个 RouterFunction.Handler。
2. FilteringWebHandler ：这是一个 WebHandler 的实现，它持有一个 WebFilter 列表，并按顺序构建出 DefaultWebFilterChain。
3. ExceptionHandlingWebHandler ：将核心处理器包裹起来，它是一个装饰器。当内部处理器冒泡出错误时，它会调用注册的 WebExceptionHandler 列表进行处理。
4. HttpWebHandlerAdapter ：将 WebFlux 的 WebHandler 转换成 Netty/Undertow/Tomcat 等服务器能调用的 HttpHandler 接口。它在第 2.3 节的 ReactorHttpHandlerAdapter 中就是被调用的对象。

这个构建链清晰地展示了 WebFlux 请求处理的层次结构：服务器适配 → 异常处理 → 过滤器链 → 核心路由处理。

5.3 响应式上下文传递：Reactor Context 取代 ThreadLocal

在传统 MVC 中，ThreadLocal 用于存储请求范围内的上下文（如 TraceId），因为它在线程绑定的模型中很可靠。但在 WebFlux 的事件循环模型中，一个请求可能在多个线程上执行，ThreadLocal 会丢失上下文。

Reactor 提供的解决方案是 Context，它是一个不可变的、类似 Map 的数据结构，沿着操作符链传递。

// 在 WebFilter 中写入上下文
webFilter((exchange, chain) -> {
    String traceId = exchange.getRequest().getHeaders().getFirst("X-Trace-Id");
    return chain.filter(exchange)
            .contextWrite(ctx -> ctx.put("TRACE_ID", traceId != null ? traceId : UUID.randomUUID().toString()));
});

// 在 Controller 或 Service 中读取上下文
Mono<String> hello = Mono.deferContextual(ctx -> {
    String traceId = ctx.get("TRACE_ID");
    return Mono.just("处理请求 " + traceId);
});

核心机制 ：contextWrite 会创建一个新的 Context 给其上游 操作符使用。这是一种逆向的、从下游向上游注入的机制。配合 SLF4J 的 Reactor 支持（如 reactor.util.context.ContextView 和 MDC），可以在日志中正确打印 TraceId，实现全链路的请求追踪。

---

6. 阻塞检测与性能陷阱

从阻塞模型迁移到非阻塞模型，最大的陷阱就是无意的阻塞调用。

6.1 一个阻塞操作的"致命一击"

在 Netty 的 Event Loop 线程（reactor-http-nio-X）上执行任何阻塞操作都是致命的。因为这些线程是单线程处理事件循环的，一个阻塞会让该线程上的所有 I/O 事件、处理任务全部排队，导致该线程服务的成百上千个连接全部"假死"，最终使服务吞吐量急剧下降，响应时间大幅增加。

• 元凶之一 ：Thread.sleep() 在任何非测试代码中。
• 元凶之二：同步 JDBC 驱动。
• 元凶之三 ：基于 InputStream 等同步 IO 的文件读写。
• 元凶之四 ：其他基于 ThreadLocal 或 synchronized 且内部有耗时操作的库。

6.2 "外科医生" BlockHound

BlockHound 是一个 Java 代理，能检测 JVM 内来自非阻塞线程的阻塞调用。

集成 ：引入 io.projectreactor.tools:blockhound 依赖，并在 main 方法的最开始安装它。

public static void main(String[] args) {
    BlockHound.install();
    SpringApplication.run(MyApplication.class, args);
}

当检测到 Thread.sleep 等在 Event Loop 线程上调用，它会抛出异常并给出详细的调用栈：

reactor.blockhound.BlockingOperationError: Blocking call! java.lang.Thread.sleep
	at java.base/java.lang.Thread.sleep(Native Method)
	at com.example.MyService.blockingMethod(MyService.java:20)
	...

6.3 隔离不可避免的阻塞：boundedElastic 的正确使用

对于无法替换的阻塞库，最后的解决方案是将其调度隔离。

Mono<String> fetchBlockingData() {
    return Mono.fromCallable(() -> {
        // unblocking company: 调用一个遗留的、阻塞的第三方库
        return LegacyClient.get("http://example.com");
    })
    .subscribeOn(Schedulers.boundedElastic()); // 让此操作在专有线程池执行
}

极其重要 ：切勿将整个 Controller 方法放到 boundedElastic 上，这会让 WebFlux 退化成一个线程池模型。应该只在最细碎的、无法避免的阻塞调用点使用 subscribeOn 进行包裹。

6.4 全链路非阻塞的典范：WebFlux + R2DBC

要发挥 WebFlux 的全部威力，必须全链路非阻塞。在数据访问层，使用响应式驱动代替 JDBC。

• R2DBC (Reactive Relational Database Connectivity) ：这是一个非阻塞的数据库驱动规范。Spring Data R2DBC 提供了基于此规范的响应式 CRUD 仓库。从 WebFilter → Router/Controller → Service → R2DBC Repository，整个调用链都返回 Mono/Flux，且没有任何点在 Netty I/O 线程上阻塞，从而实现了极致的资源利用和吞吐量。

---

7. 生产事故排查专题

7.1 事故一：高并发下响应极慢的"幽灵阻塞"

• 现象：服务上线初期负载低，一切正常。某次促销活动，QPS 从 10 突增至 500。应用瞬间响应极慢，几乎所有接口超时，但服务器 CPU 使用率却很低。
• 排查思路 ：
  1. 通过 jstack 打印线程堆栈，发现大量 reactor-http-nio-X 线程处于 WAITING 或 BLOCKED 状态。
  2. 查看堆栈信息，直接定位到 com.example.repository.UserRepository.findById 方法。
  3. 在代码中审查该仓库实现，发现它是一个 JPA (javax.persistence)仓库。Spring Data JPA 底层使用的是 JDBC，而 JDBC 驱动是同步阻塞的。
• 根因 ：在 WebFlux 的高并发场景下，所有 reactor-http-nio-X 线程被阻塞的 JDBC 调用占满，事件循环机制彻底失效。每个请求都在等待 JDBC 返回，而 CPU 并未执行有效计算，导致 CPU 使用率低但服务完全不可用。
• 解决 ：
  • 短期 ：将有问题的调用用 Mono.fromCallable().subscribeOn(Schedulers.boundedElastic()) 包裹，将阻塞压力"卸载"到 boundedElastic 线程池，让 Netty I/O 线程立即释放。
  • 长期：将该模块的持久层技术栈迁移到 R2DBC，实现真正的全链路非阻塞。
• 最佳实践 ：
  • 技术选型评审阶段，必须明确阻塞库与 WebFlux 的兼容性。
  • 开发环境强制集成 BlockHound，尽早暴露潜在的阻塞调用。
  • 建立线程池监控，对 reactor-http-nio-*, boundedElastic-* 等线程池的线程状态、队列大小进行可视化监控和告警。

sequenceDiagram participant JMeter as 压力测试 (500 TPS) participant WebFlux as WebFlux App (10 NIO线程) participant Service as 业务Service participant JDBC as 同步JDBC驱动 JMeter->>+WebFlux: 500个HTTP请求瞬间涌入 loop NIO线程处理 WebFlux->>+Service: ![NIO线程] 调用 findById Service->>+JDBC: ![NIO线程] 执行阻塞SQL查询 Note over JDBC: SQL执行耗时50ms JDBC-->>-Service: 返回结果 Service-->>-WebFlux: 返回响应 end Note over WebFlux: 10个NIO线程全部阻塞在JDBC调用上，
剩余490个请求在TCP缓冲区排队或超时。

• 图表主旨概括：该序列图模拟了阻塞 JDBC 调用导致 NIO 线程池耗尽的事故场景。
• 逐层/逐元素分解 ：压力测试工具向 WebFlux 应用发起 500 个并发请求。应用的 10 个 Netty I/O 线程忙于处理请求，但在执行 Service 层时，因为 JDBC 驱动的同步阻塞特性，每个线程都被挂起等待数据库的 50ms 响应。在此期间，没有线程能处理新的 I/O 事件。
• 设计原理映射 ：事件循环模型的阿喀琉斯之踵------单线程阻塞。同步阻塞破坏了非阻塞 IO 的协作式调度，将异步事件循环退化为同步线程池，其并发能力瞬间从支撑成千上万连接退化到线程池大小。
• 工程联系与关键结论 ：WebFlux 的性能优化首先是"非阻塞化"，其次才是代码逻辑。 一个阻塞点足以毁掉整个响应式架构的所有优势。结合前一章，WebClient 的非阻塞调用正是为了在这种模型中保持响应式流的完整性。

7.2 事故二：流式查询引发的 OOM（内存溢出）

• 现象 ：一个提供 CSV 导出的接口，采用 application/stream+json 流式响应。在少量数据时功能正常，但当用户在后台导出百万级数据时，服务进程的内存被迅速耗尽，导致 OutOfMemoryError，进程崩溃。
• 排查思路 ：
  1. Heap dump 分析显示，大量 DataBuffer 对象占据了老年代，而它们被一个 Flux 管道中的内部缓冲区持有。
  2. 检查导出接口的 Controller 代码，发现服务从数据库查询出一个 Flux<Record>，然后直接返回，由 Spring 序列化并写入。一切看起来都很"流式"。
  3. 进一步检查，发现在写入响应体之前，有一个 WebFilter 试图记录整个响应体大小。它使用 exchange.getResponse().bufferFactory().join() 将整个响应体 DataBuffer 流聚合成一个单一的 DataBuffer 来获取大小。
• 根因 ：WebFilter 中的 join() 操作是一个无界缓冲 。它从下游的 Flux 中请求所有数据并缓存到内存，完全破坏了流式处理的背压机制。对于百万级的数据流，操作系统 TCP 层的背压本可以让数据库生产数据的速度与客户端消费速度匹配，但 join() 操作将其变成了一个内存"黑洞"。
• 解决 ：
  • 移除任何会无界缓冲整个响应式流的操作。
  • 如果确实需要记录响应体大小，可以使用一个包装的 ServerHttpResponseDecorator，在 writeWith 方法中"窥探"每个 DataBuffer 的大小并累加，而不是聚合它们。
• 最佳实践 ：
  • 深入理解每一个 Reacor 操作符的背压特性。任何 collectList(), buffer(), join() 等将 Flux 聚合到内存的操作，在流式场景下都必须审慎分析其上游数据量是否可控。
  • 对于流式 API，在集成测试中必须包含大数据量场景的模拟，并使用 JProfiler/JVisualVM 等工具观察内存的波动。

---

8. 面试高频专题

1. Spring WebFlux 和 Spring MVC 的本质区别是什么？

   • 标准回答：本质区别在于线程模型和工作方式。MVC 基于 Servlet，是同步阻塞模型，一个请求需要一个线程去处理，线程池大小决定并发上限。WebFlux 基于 Reactor 和 Netty，是异步非阻塞事件循环模型，用少量固定线程处理海量并发连接。另一个区别是编程范式：MVC 是命令式编程，WebFlux 是响应式声明式编程。
   • 追问与加分回答 ：
     • 追问1 ：在什么场景下应该选择 WebFlux？答：高并发网关、流数据应用、需要与外部服务进行大量非阻塞 IO 交互的微服务。如果应用本身是计算密集型，或使用了大量阻塞库（如 JDBC），MVC 可能更简单直接。
     • 追问2 ：Servlet 3.1 引入了异步，它和 WebFlux 的异步有何不同？答 ：Servlet 3.1 异步仍然是基于请求/响应绑定的线程模型，虽然可以将耗时操作放到另一个线程池，避免阻塞容器线程，但核心的请求体/响应体读写依然是基于阻塞的 InputStream/OutputStream。而 WebFlux 从网络 IO 层就是基于 NIO 的，能够实现端到端的非阻塞与背压。
     • 追问3 ：能同时在一个应用里使用 MVC 和 WebFlux 吗？答 ：Spring Boot 应用本身不能。它们是两种不同的 Web 应用类型。但你可以运行一个 MVC 应用并使用 WebClient 调用 WebFlux 服务，反之亦然。

2. 什么是背压？在 WebFlux 中如何处理背压？

   • 标准回答 ：背压是指慢速消费者能通知生产者放缓生产速度的一种流量控制机制。在代码层面，通过 Subscription.request(n) 信号向上游传递。在 WebFlux 中，从 TCP 连接层、请求体读取到响应体写入，是全链路支持背压的。
   • 追问与加分回答 ：
     • 追问1 ：flatMap 的背压是如何工作的？答 ：它通过 prefetch 参数（默认256）批量向上游请求，然后由一个内部队列协调多个内层流的请求，尽力将需求信号合并且透明化。但这也意味着背压信号不是完全 1:1 传递的。
     • 追问2 ：如果上游不支持背压（如定时器事件）怎么办？答 ：需要使用 onBackpressureBuffer, onBackpressureDrop, onBackpressureLatest 等操作符来处理生产过剩。缓冲区可以设置最大尺寸和溢出策略。
     • 追问3 ：limitRate() 和背压有什么关系？答 ：limitRate(100) 是一种下游背压保护机制。它告诉下游"即使我一次 request 了大量数据，也请分批，每次最多给我100个"。这可以防止一次性收到大量数据导致处理缓慢。

3. WebFlux 的线程模型是怎样的？为什么它能用少量线程支撑高并发？

   • 标准回答 ：WebFlux 默认基于 Netty 的 Event Loop Group。每个 Event Loop 是一个单线程，负责监听 I/O 事件并进行多路分发。由于没有阻塞，一个事件循环线程可以非常快速地处理成千上万个连接的 I/O 读写事件。应用的业务逻辑也在此线程执行，因此必须是异步非阻塞的。对于阻塞调用，用 Schedulers.boundedElastic() 隔离。
   • 追问与加分回答 ：
     • 追问1 ：Netty 的 Boss 和 Worker 线程组分别做什么？答 ：Boss Group（通常1个线程）负责接受客户端的连接；Worker Group 负责处理连接上的 I/O 读写和业务处理。在 Reactor Netty 中，HttpServer 默认使用一个 Event Loop Group，通过配置参数 reactor.netty.ioWorkerCount 调整。
     • 追问2 ：如果一个请求需要访问 Redis、DB 和另一个微服务，这个请求是在多个线程上完成的吗？答 ：如果整个链路（Redis reactive driver, R2DBC, WebClient）都是非阻塞的，那么整个请求的处理可能在同一个 Netty I/O 线程上完成，除非中间有显式的线程调度（如 subscribeOn 或 publishOn）。
     • 追问3 ：ThreadLocal 在 WebFlux 中为什么不推荐？答 ：因为一个请求的生命周期可能由多个线程协作完成，ThreadLocal 会在跨线程时丢失数据。应使用 Reactor 的 Context 来传递请求上下文，如 TraceId。

4. 如何检测和防止响应式应用中的阻塞调用？

   • 标准回答 ：使用 BlockHound。它是一个 Java Agent，可以在 JVM 层面检测 Thread.sleep, synchronized, 阻塞 IO 调用等是否发生在非阻塞线程（如 reactor-http-nio-*）上，如果发现会主动报错。防止的最佳实践是全链路非阻塞，并在开发环境启用 BlockHound。
   • 追问与加分回答 ：
     • 追问1 ：BlockHound 的原理是什么？答 ：它基于 ByteBuddy 对 java.lang.Thread, java.util.concurrent.locks.LockSupport, 原生 IO 类等关键阻塞方法进行字节码增强，在执行时检查当前线程是否被标记为"非阻塞"。
     • 追问2 ：除了 BlockHound，还有什么排查方法？答 ：线程 dump (jstack)。如果在高负载时，发现大量 reactor-http-nio-* 线程都处于同一业务代码或 JDBC 调用的阻塞状态，这就是很明显的信号。
     • 追问3 ：如果就是要读取一个巨大的本地文件，怎么做到非阻塞？答 ：Java 7+ 的 AsynchronousFileChannel 提供了非阻塞的文件 IO。Spring 的 DataBufferUtils 封装了它，可以返回一个 Flux<DataBuffer>，从而实现非阻塞的文件流式读取。

5. Reactor 中如何优雅地处理错误？有哪些操作符可用？

   • 标准回答 ：核心有 onErrorReturn（返回静态降级值）、onErrorResume（动态返回备选流）、onErrorMap（翻译异常）、retry/retryWhen（重试）。onErrorResume 是最强大的，因为它可以基于异常类型和内容，灵活决定是降级、重试还是继续抛出。
   • 追问与加分回答 ：
     • 追问1 ：doOnError 和 onErrorResume 区别？答 ：doOnError 是副作用操作符，只用于观察错误（如记录日志），不改变信号的传播。onErrorResume 是恢复操作符，它会消耗掉错误信号并替代为一个新的值或流，让流得以恢复。
     • 追问2 ：retryWhen 和 retry 有何不同？答 ：retry 是简单的次数重试。retryWhen 允许你用一个 Flux 来控制重试的策略，比如指数退避（Retry.backoff(5, Duration.ofSeconds(1))），它可以灵活控制重试次数、间隔，甚至可以在重试时加入条件判断。
     • 追问3 ：在 WebFlux 中，如果 onErrorResume 返回了一个 Mono，它会被框架正确渲染成 HTTP 响应吗？答 ：是的。WebFlux 的 ServerResponse 最终还是基于 Mono/Flux。onErrorResume 返回的备选流会被框架视同正常的成功结果，写入 HTTP 响应体。真正的"错误"是那些没有在应用层被处理的，最终传播到 WebExceptionHandler 的异常。

系统设计题

设计一个基于 WebFlux 的实时行情推送服务，要求能同时支持成千上万客户端订阅不同股票代码，并且各个客户端的消费速度可能不同。请利用 WebFlux 的 SSE 和背压机制进行设计，并说明如何处理连接断开和重连。

• 设计要点 ：
  1. 股票-事件总线 ：为每个股票代码建立一个全局的且可广播的 Flux，如 Sinks.Many<PriceData>。这是一个热流，当最新行情到达时，向所有订阅者推送。
  2. SSE 端点 ：提供 @GetMapping(value = "/{symbol}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)。Controller 方法返回 Flux<ServerSentEvent<PriceData>>。
  3. 背压处理 ：不同客户端网速和处理能力不同。但 Sinks.Many 默认是推模型。如果客户端慢，Sinks.Many 的 emitNext 会因为下游的背压而失败或阻塞。解决方案是使用 Sinks.Many 的 onBackpressureBuffer 策略，为每个客户端连接创建一个独立的、有界 的缓冲区。当缓存满时，可丢弃旧数据（Sinks.EmitFailureHandler.busyLooping(Duration)）以保障最新行情的实时性。
  4. 连接断开与资源清理 ：当客户端断开连接，SSE 的写入会完成。我们需要在 Flux 添加 doFinally 或 doOnCancel，在该信号处理程序中，将对应的 Sinks.Many 的订阅取消，并清理为该连接创建的背压队列，防止内存泄漏。
  5. 心跳机制 ：为避免代理服务器超时断连，SSE 流中应定期写入一条心跳事件。可以用 Flux.interval 与行情 Flux 进行 merge，并设置 Content-Type: text/event-stream。

---

WebFlux/Reactor 核心概念速查表

概念/组件	角色/定位	关键特性	WebFlux 集成点
Reactive Streams	异步非阻塞背压流处理规范	Publisher, Subscriber, Subscription, Processor	整个 WebFlux 的基石，Reactor 是其实现
Mono	0..1 个异步结果的发布者	惰性、组合、错误恢复	表示单个 HTTP 响应、单个 DB 查询结果
Flux	0..N 个异步序列的发布者	惰性、背压、流式处理	表示 SSE、流式 JSON、请求体元素流
Schedulers	线程池抽象与调度工具	parallel, single, boundedElastic, immediate	分离阻塞调用 (boundedElastic)，管理计算线程
Event Loop	Netty 的非阻塞 I/O 处理模型	单线程处理多连接事件，无锁化	WebFlux 默认运行时，处理所有非阻塞 I/O
Backpressure	慢速消费者控制数据流速的机制	request(n) 信号，缓冲区与丢弃策略	HTTP 读写层、管道操作符，保证内存稳定
WebFilter	响应式 Web 过滤器	基于 Mono 组装，支持前置/后置	替代 HandlerInterceptor，实现认证、日志等
Context	Reactor 的请求上下文传递机制	不可变，沿操作符链传递，替代 ThreadLocal	传递 TraceId、认证信息等请求级别数据
BlockHound	阻塞调用检测代理	JVM Agent，运行时检测非阻塞线程上的阻塞操作	开发/测试环境集成，防止阻塞泄漏至 Event Loop
R2DBC	响应式关系型数据库连接规范	全异步非阻塞的数据库驱动	消除数据访问层的最后一个阻塞瓶颈