WebFlux实践与选型对比详解
定位：第 07 篇，讲透全链路响应式的实践要求、WebClient、响应式数据访问，以及 MVC 与 WebFlux 的选型决策
适用版本：Spring Framework 6.x（JDK 17+）
目录
- 一、全链路响应式
- 二、WebClient
- 三、响应式数据访问
- 四、MVC vs WebFlux 选型
- 五、总结
- 六、常见高频面试题
一、全链路响应式
1.1 收益的前提：端到端非阻塞
WebFlux 的收益建立在整条调用链都非阻塞之上：
请求 → WebFlux → WebClient（调下游）→ 响应式驱动（DB/缓存）→ 返回 非阻塞 非阻塞 非阻塞任一环节阻塞（如同步 JDBC、阻塞的 HTTP 客户端），EventLoop 就被占住，收益归零甚至更差——这是"用了 WebFlux 却没变快"的最常见原因。
1.2 阻塞环节的两种处理
| 方式 | 做法 |
|---|---|
| 换响应式实现 | R2DBC、响应式 Mongo/Redis、WebClient（首选） |
| 隔离到弹性调度器 | 无法替换时，subscribeOn(Schedulers.boundedElastic())把阻塞段挪出 EventLoop |
第二种是妥协：阻塞仍占线程，只是不占宝贵的 EventLoop。
二、WebClient
2.1 定位
响应式非阻塞 HTTP 客户端，替代 RestTemplate（后者已进入维护模式，新项目用 WebClient）。
2.2 用法
WebClientclient=WebClient.create();Mono<User>user=client.get().uri("/users/{id}",id).accept(MediaType.APPLICATION_JSON).retrieve().bodyToMono(User.class);// 返回 Mono，惰性Flux<Order>orders=client.get().uri("/orders").retrieve().bodyToFlux(Order.class);要点：与 Reactor 一致，调用链在 subscribe 前不发起请求；WebFlux 中直接返回 Mono/Flux 给框架。
2.3 错误与配置
.retrieve().onStatus(...)：按状态码转异常 .exchangeToMono(...)：拿到完整响应自行处理 构建时配置：baseUrl、超时（连接/响应）、连接池、编解码器超时必配——响应式客户端不配超时同样会无限等待（01 篇纪律在响应式下依然成立）。
三、响应式数据访问
3.1 驱动选择
| 存储 | 响应式方案 |
|---|---|
| 关系库 | R2DBC（Reactive Relational DB Connectivity） |
| MongoDB | Spring Data Reactive Mongo |
| Redis | ReactiveRedisTemplate |
传统 JDBC 是阻塞式——在 WebFlux 里直接用它会阻塞 EventLoop，必须换 R2DBC 或隔离到弹性调度器。
3.2 与 Spring Data 的整合
Spring Data 提供响应式仓库接口：
publicinterfaceUserRepoextendsReactiveCrudRepository<User,String>{}// 方法返回 Mono<User> / Flux<User>3.3 响应式事务
响应式链路不能依赖 ThreadLocal 传递事务连接（线程会切换） → 用 ReactiveTransactionManager + @Transactional（响应式支持） → 事务上下文通过 Reactor Context 传播这是响应式与命令式事务模型的本质差异：连接/会话不再绑定线程，而随订阅上下文流动。
四、MVC vs WebFlux 选型
4.1 决策维度
| 维度 | 倾向 MVC | 倾向 WebFlux |
|---|---|---|
| 并发形态 | 常规并发 | 海量连接 + IO 密集（网关、推送、聚合） |
| 生态 | 依赖多为阻塞（传统 JDBC/SDK） | 依赖支持响应式 |
| 团队 | 熟悉同步栈 | 能接受响应式学习曲线 |
| 调试成本 | 堆栈直观 | 异步链调试复杂 |
| CPU 密集 | MVC 即可（响应式无收益） | — |
4.2 典型适用与不适用
适合 WebFlux：API 网关、实时推送（SSE/WS）、流式数据、聚合编排大量下游 不适合：常规 CRUD 业务系统、依赖大量阻塞库、团队无响应式经验4.3 虚拟线程（JDK 21）的新变量
虚拟线程让"同步写法 + 高并发"重新可行： 每个请求一个（廉价的）虚拟线程，阻塞不再昂贵 → 部分"为并发上 WebFlux"的场景，可用 MVC + 虚拟线程替代 → 保留同步编程模型，降低复杂度选型时要把虚拟线程纳入考量：若 JDK 21+ 可用，许多场景"同步 + 虚拟线程"比响应式更划算。
4.4 渐进式策略
不必非黑即白： ① MVC 项目里，个别接口返回 CompletableFuture/Mono（Spring MVC 支持异步返回值） ② 用 WebClient 替换 RestTemplate（即使非 WebFlux） ③ 确有收益的模块单独上 WebFlux五、总结
- 全链路响应式：收益要求端到端非阻塞，任一阻塞环节使收益归零；阻塞优先换响应式实现，次选隔离到 boundedElastic。
- WebClient：响应式客户端替代 RestTemplate；惰性执行、需配超时；错误用 onStatus 处理。
- 响应式数据访问：R2DBC/响应式 Mongo/Redis；响应式仓库返回 Mono/Flux；事务靠 ReactiveTransactionManager + Context 传播。
- 选型：海量连接 + IO 密集 + 生态支持才选 WebFlux；常规业务用 MVC；JDK 21 虚拟线程让"同步高并发"重新成为简单选项；可渐进混用。
六、常见高频面试题
1. 为什么说 WebFlux 需要"全链路响应式"才有收益？
要点：WebFlux 用少量 EventLoop 线程服务所有连接，前提是这些线程永不被阻塞。若链路中某环节阻塞（同步 JDBC、阻塞 HTTP 客户端），EventLoop 被占住，该线程上所有连接停摆——非阻塞的收益被阻塞点完全抵消，甚至因模型复杂度而更差。所以必须端到端非阻塞（响应式驱动），或把阻塞环节隔离到弹性调度器。
2. WebClient 和 RestTemplate 的区别？
要点：RestTemplate 是同步阻塞客户端（已进入维护模式，不再加新功能）；WebClient 是异步非阻塞、基于 Reactor，返回 Mono/Flux，支持背压与流式，可在 WebFlux 与 MVC 中使用。新项目推荐 WebClient。使用差异：WebClient 调用链惰性（不订阅不发起）、需自行处理错误（onStatus）、必须配置超时与连接池。
3. 在 WebFlux 里访问关系型数据库怎么办？
要点：传统 JDBC 阻塞，直接在响应式链上用会占住 EventLoop。方案：① 首选 R2DBC——关系库的响应式驱动，配合 Spring Data R2DBC，仓库返回 Mono/Flux；② 无法迁移时，把 JDBC 调用用 subscribeOn(Schedulers.boundedElastic()) 隔离到弹性线程池（妥协方案，仍占线程）。事务用 ReactiveTransactionManager。
4. 响应式事务和传统事务有什么不同？
要点：传统（命令式）事务把连接绑定到当前线程（ThreadLocal），方法调用链天然共享。响应式链执行跨线程切换，ThreadLocal 失效——连接不能绑线程。解法：ReactiveTransactionManager + @Transactional 的响应式支持，事务上下文通过 Reactor Context（随订阅流动而非线程）传播，保证同一流上的操作共享事务。这是响应式模型"线程不持有状态"的体现。
5. 什么场景适合用 WebFlux？
要点：IO 密集 + 海量并发连接的场景收益最大：API 网关（大量转发与聚合）、实时推送（SSE/WebSocket 服务）、流式数据处理、需要编排大量下游调用的聚合服务。不适合：常规 CRUD（复杂度不划算）、CPU 密集（响应式无收益）、依赖生态多为阻塞库、团队无响应式经验。原则：并发瓶颈真实存在且生态支持，才选。
6. JDK 21 虚拟线程对 MVC vs WebFlux 选型有什么影响？
要点：虚拟线程让"每个请求一个线程"的同步模型重新廉价——阻塞时虚拟线程被挂起而非占用平台线程，高并发不再需要海量平台线程。于是许多"为并发上 WebFlux"的场景，可以用 MVC + 虚拟线程替代，保留同步编程模型与简单调试，复杂度远低于响应式。选型时：JDK 21+ 可用且依赖阻塞为主，虚拟线程往往是更优解；响应式保留给流式/背压等特殊需求。
7. 阻塞代码必须保留时，在 WebFlux 里怎么处理？
要点：用调度器隔离：把阻塞段用 subscribeOn 或 publishOn 切到 Schedulers.boundedElastic()（专为阻塞设计的弹性线程池），让阻塞发生在独立池而非 EventLoop。示例：Mono.fromCallable(blockingCall).subscribeOn(boundedElastic())。注意这是妥协——阻塞仍消耗线程与资源，只是保护了 EventLoop；能换响应式实现（R2DBC、WebClient）应优先换。
8. WebClient 如何处理错误和超时？
要点：错误：.retrieve().onStatus(谓词, 响应→异常) 把 4xx/5xx 转为自定义异常在链上处理；或用 .exchangeToMono 拿完整响应自行决定。超时：构建时通过 HttpClient 配置连接超时与响应超时（reactor-netty），或链上 .timeout(Duration)。纪律：不配超时的客户端会无限等待，与同步调用一样必须设超时（01 篇的通用纪律在响应式下不变）。
9. 能只用 WebClient 不上 WebFlux 吗？
要点：可以。WebClient 是独立组件，在 Spring MVC（同步）项目里也能用，适合调用下游的异步编排、并行聚合多个远程结果（返回 Mono/Flux 组合），或替换 RestTemplate。此时 Web 入口仍是 MVC 的同步模型，只是出站调用用响应式客户端。这体现了"按需引入响应式能力"的渐进策略，不必整体迁移。
10. 团队要引入 WebFlux，有哪些风险和准备？
要点：风险：① 学习曲线陡（响应式思维、操作符、惰性执行）；② 调试排障难（异步堆栈不连贯）；③ 生态约束（阻塞依赖要换或隔离）；④ 运维监控方式不同。准备：先小范围试点（如一个网关或聚合服务）验证收益；统一阻塞处理规范（换响应式驱动或隔离调度器）；建立响应式测试（StepVerifier）与观测（上下文传播日志）；评估虚拟线程是否是更简单的替代。避免全量盲目迁移。
