大家好，我是程序员天天困。
一个挺常见的翻车现场：Controller 写着 WebFlux，Repository 却还挂着 JDBC，压测一上，线程池先炸。这种「半响应式」的坑，说到底还是没分清 R2DBC vs JDBC 的差别。今天（2026 年 8 月）按 Spring Boot 3.x 的常见用法，把 R2DBC vs JDBC 讲透，你读完能判断自己的项目该不该上响应式数据库访问。点个收藏，我们开始。
一、R2DBC vs JDBC，差的不是 API 花哨
很多人一搜就看到一堆定义。我想先把话说死：R2DBC vs JDBC 的核心差别，是线程在等数据库时能不能干别的事。
JDBC（Java Database Connectivity）：Java 访问关系库的老标准，同步阻塞 I/O。类比：服务员端着盘子站在厨房门口死等出菜，这会儿别的桌也顾不上。
R2DBC（Reactive Relational Database Connectivity）：面向响应式流的关系库访问规范，非阻塞。类比：服务员把单子交给厨房，转身去别桌倒水；菜好了再回来上。
Spring Data R2DBC：在 R2DBC 驱动之上的 Spring Data 抽象，Repository 返回 Mono / Flux，方便和 WebFlux 拼成一条响应式链路。
你平时用的 JdbcTemplate、Spring Data JPA，底层几乎都踩在 JDBC 上。2024～2026 年的 Spring Boot 3.x 项目里，响应式栈要走通数据库，常见入口是 spring-boot-starter-data-r2dbc，而不是硬把 JPA 塞进 WebFlux。
二、Spring Boot 响应式编程里，两套写法长什么样
在 Spring Boot 里谈响应式编程，数据库这一层要和 Web 层同一套线程哲学，否则只是半截改造。
阻塞写法（Web MVC + JDBC / JPA）大家太熟了，示意一下：
@GetMapping("/devices/{id}")
public Device get(@PathVariable Long id) {
return deviceRepository.findById(id)
.orElseThrow(); // 线程在这里干等数据库
}
响应式写法（WebFlux + Spring Data R2DBC）大致是：
@GetMapping("/devices/{id}")
public Mono<Device> get(@PathVariable Long id) {
return deviceRepository.findById(id); // Mono：0~1 条，不堵工作线程
}
依赖上通常是：
<!-- 响应式 Web + R2DBC -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-r2dbc</artifactId>
</dependency>
<!-- 再加具体库驱动，如 r2dbc-postgresql -->
注意：spring.datasource.url 那套 JDBC 配置，和 spring.r2dbc.url 不是一回事。混配是常见翻车点。Schema 迁移（Flyway / Liquibase）往往仍走 JDBC 连接——这很正常，迁移本来就偏批处理，不必强行响应式。
三、WebFlux 搭配 R2DBC：为什么「半响应式」最亏
WebFlux 搭配 R2DBC 才算闭环；WebFlux 底下继续 JDBC，高并发时经常两头不讨好。
原因很直白：WebFlux 默认线程很少，靠非阻塞撑并发。你在里面调用阻塞 JDBC，等于把稀缺线程钉在数据库等待上。很多人觉得「上了 WebFlux 就响应式了」，结果线程模型比纯 MVC 还脆。
公开压测里（例如 Maarten Smeets 对 Web MVC/WebFlux × JDBC/R2DBC 四组合的对比）有个挺稳的共识：
1）高并发时，WebFlux + R2DBC 的延迟和吞吐通常更好，单请求的 CPU/内存开销也更省。
2）低并发时，Web MVC + JDBC 往往更简单，有时还更快——别为了时髦交学费。
3）WebFlux + JDBC 是最容易踩的坑：看起来先进，实际把阻塞塞进了小线程池。
下面这张图把两种等待方式并排放一下：
拿一个示例场景来说（设备状态查询接口）：QPS 不高时，JDBC 完全够用；一旦网关侧出现「连接多、每请求等库时间长」的情况，半截 WebFlux 会比老老实实 MVC 更难排障。
四、一张表看清该偏向谁
| 维度 | JDBC / Spring JDBC·JPA | R2DBC / Spring Data R2DBC |
|---|---|---|
| I/O 模型 | 同步阻塞 | 非阻塞、响应式流 |
| 典型组合 | Web MVC + HikariCP | WebFlux + R2DBC 连接池 |
| 生态成熟度 | 极成熟，资料多 | 可用，但关联映射弱 |
| 复杂 ORM | JPA/Hibernate 很强 | 基本无懒加载/复杂关联 |
| 学习成本 | 团队大多已会 | 要吃透 Reactor 背压 |
| 适合负载 | 中低并发、复杂事务 | 高并发、等 I/O 多 |
可能有人会问：Virtual Thread（Project Loom）出来了，R2DBC 是不是没必要了？
我觉得还没到「二选一作废」的时候。虚拟线程让阻塞 JDBC 在很多场景更香，尤其团队不想学 Reactor；但如果你已经全栈 WebFlux、并且链路里大量背压与流式处理，R2DBC 仍然是更贴合的数据库接口。选型看团队能力与链路长什么样，别只看热搜词。
五、物联网高并发数据库选型：什么时候真该上 R2DBC
物联网高并发数据库选型里，R2DBC 吃香的是「连接多、等待多」的接入层，不是所有 IoT 模块都该换。
有人觉得「物联网项目好像都在用 R2DBC」，这话只对了一半。更准确的说法是：
1）设备遥测上报、网关扇入、海量短连接查询——这类 Spring Boot 服务，WebFlux + R2DBC（或响应式 NoSQL）出现频率更高，因为线程数撑不住「一设备一阻塞等待」。
2）设备档案管理、计费、权限、报表导出——事务复杂、关联多，JDBC/JPA 通常更稳。
3）很多 IoT 系统其实是混合架构：接入层响应式，后台管理仍阻塞式。别为了统一技术栈硬拧。
落地时我建议按这个顺序问自己三句：
1）瓶颈是不是在「等数据库 / 等下游」，而不是纯 CPU 计算？
2）团队能不能维护 Mono/Flux 链路与背压，而不是只会 Optional？
3）领域模型要不要重度关联与 JPA 懒加载？要的话，先别上 R2DBC。
三句里有两句答「不」，就老实用 JDBC。
六、Spring Data R2DBC 适用场景，上之前先认清边界
Spring Data R2DBC 适用场景很窄但很锋利：全链路非阻塞、模型相对扁平、愿意手写关联装配。
上之前把这几条记牢：
1）别指望 JPA 那套关联魔法。 Spring Data R2DBC 基本不帮你懒加载一对多；要聚合就自己 flatMap / zipWith 拼。BellSoft 等技术文也反复强调这一点——不是偷懒，是响应式映射很难既不阻塞、又不把领域模型绑死在 Reactor 类型上。
2）驱动覆盖要先查。 PostgreSQL、MySQL、SQL Server、H2、MariaDB、Oracle 等已有 R2DBC 驱动，但版本与功能成熟度参差不齐，上生产前用你的库做一轮真实压测。
3）事务是响应式事务。 @Transactional 那套心智要换成 TransactionalOperator / 响应式事务管理器，调试链路比同步难一截。
4）调试与招聘成本。 出问题看堆栈时，Reactor 调用链对新手不友好。团队没人熟，就别拿核心账务系统去练手。
可能有人会问：能不能 Web MVC 配 R2DBC？
能跑，但收益通常不如「WebFlux + R2DBC」一整条。阻塞 Web 层配非阻塞数据层，心智分裂，我一般不推荐当目标架构。
说白了：只有整条链路都非阻塞时，R2DBC vs JDBC 才值得纠结；否则直接 JDBC 往往更省事、更稳。 物联网接入层可以大胆评估 R2DBC，CRUD 后台没必要为了简历关键词硬上。
我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你做 R2DBC vs JDBC 选型时，最终站哪边？踩过半响应式的坑吗。
