R2DBC 与响应式数据库与 RSocket 与响应式网络

• TransactionalDatabaseClient 的事务边界
• 事务与连接的绑定
• beginTransaction/commit/rollback 的使用

R2DBC 的 TransactionalDatabaseClient（或 DatabaseClient.inTransaction）提供事务支持，但事务边界限定在"同一响应式连接"上：事务内的所有操作必须复用同一连接，事务开始用 beginTransaction，提交用 commitTransaction，回滚用 rollbackTransaction。inTransaction 会为事务内的操作绑定一个连接，保证事务的原子性。由于事务绑定连接，事务内不能切换连接（不能跨数据源、不能跨远程服务），且事务方法需在响应式链上执行，不能阻塞或切换线程。事务边界 = 同一连接上的操作序列。跨连接或跨服务的一致性需用分布式事务方案（Saga/Outbox）。理解事务边界对正确设计响应式数据库操作至关重要。

R2DBC 事务的核心边界是"单连接"。beginTransaction/commit/rollback 在同一连接上执行。跨连接/跨服务无法用本地事务，需分布式方案。响应式事务链上操作保证原子性。

• 传输层（TCP/HTTP2）、流控、背压、多路复用
• 四种交互模型
• 微服务通信场景适配

RSocket 与 gRPC 都是高性能 RPC/通信框架，但侧重点不同。传输层：gRPC 基于 HTTP/2（支持多路复用、流式、二进制），RSocket 可基于 TCP/WebSocket（自带多路复用 Frame 机制）。流控与背压：RSocket 在应用层提供原生背压（request(n) 信用机制），支持四种交互模型（request-response、request-stream、fire-and-forget、channel），响应式背压是核心；gRPC 基于 HTTP/2 的流控制，背压较弱，更适合传统 RPC。多路复用：gRPC 靠 HTTP/2 多路复用，RSocket 靠帧级多路复用。适用场景：gRPC 适合微服务间的强类型 RPC、跨语言、需要服务契约（protobuf）的场景；RSocket 适合需要响应式背压、单向推送（fire-and-forget）、双向流（channel）、长连接响应式通信的场景（如流式事件、IoT、实时数据）。选择依据：强类型 RPC 与生态用 gRPC，响应式流与背压优先用 RSocket。

对比核心是"传输/复用/流控/背压"。gRPC 强在 HTTP/2 多路复用与强类型契约，RSocket 强在应用层背压与四种交互模型。场景适配取决于是否需要响应式背压与流式交互。

• DatabaseClient 的 SQL 操作 API
• execute/query/select 等
• 参数绑定与结果映射

DatabaseClient 是 Spring Data R2DBC 提供的响应式数据库操作 API，用于执行 SQL 并返回 Mono/Flux。基本用法：通过 DatabaseClient.create(ConnectionFactory) 创建，或注入 Spring Bean。常用方法：sql("...").bind("param", value).map(...) 或 .fetch().one()/all()/rowsUpdated()；sql 执行 SQL，bind 绑定参数，map 映射结果行，fetch 决定取单条/多条/影响行数。也可以用 sql(...).bind(...).execute() 执行写操作。DatabaseClient 支持绑定参数、结果映射、事务（inTransaction）。相比 JdbcTemplate，DatabaseClient 返回 Mono/Flux 是响应式的，全程非阻塞。它是 R2DBC 的核心编程接口。

DatabaseClient 是响应式 SQL 操作 API，链式：sql、bind、map/fetch。返回 Mono/Flux，非阻塞。相比 JdbcTemplate 是响应式版本。

• R2DBC 的 statement 批处理（add 多条）
• JDBC 批处理（addBatch/executeBatch）
• 响应式批处理与结果处理

R2DBC 支持批量执行：通过 Statement 的 add() 方法添加多条绑定参数的语句，然后 execute() 一次性执行，返回 Flux 或结果。与 JDBC 批处理（PreparedStatement.addBatch/executeBatch）相比：R2DBC 的批处理是响应式的，execute 返回 Flux 结果，可异步处理；JDBC 批处理是同步阻塞的。R2DBC statement 支持绑定多条参数（add 一次绑定一组），execute 后通过 Flux 消费每个语句的结果。差异还包括：R2DBC 批处理适用于大批量插入/更新的性能优化，但需注意不同驱动的批量支持程度；结果处理是响应式流。多语句执行（execute 多条 SQL）在 R2DBC 需逐条执行或按驱动支持，与 JDBC 的多语句（allowMultiQueries）不同。

核心差异是"响应式 vs 同步"。R2DBC 批处理用 add() 累积参数、execute() 异步执行，返回 Flux；JDBC 用 addBatch/executeBatch 同步。R2DBC 批处理专注性能优化。

• MySQL 的 R2DBC 驱动（dev.miku:r2dbc-mysql）
• PostgreSQL 的 R2DBC 驱动（io.r2dbc:r2dbc-postgresql）
• 驱动配置与连接

PostgreSQL 的官方 R2DBC 驱动是 io.r2dbc:r2dbc-postgresql（PostgresConnectionFactory），MySQL 的常用驱动是 dev.miku:r2dbc-mysql（MySqlConnectionFactory，社区维护）。选用时通过引入对应依赖并配置 ConnectionFactory（或 Spring Data R2DBC 的配置：spring.r2dbc.url 等）建立连接。不同驱动对特性的支持有差异（如类型、协议特性、性能），需按数据库选驱动。驱动配置涉及 URL、用户名、密码、连接池。Spring Boot 通过 spring.r2dbc.url（r2dbc:mysql://... 或 r2dbc:postgresql://...）自动配置。选用时注意驱动维护活跃度与版本兼容。

R2DBC 驱动按数据库区分：PostgreSQL 用官方 r2dbc-postgresql，MySQL 用社区 r2dbc-mysql。通过 spring.r2dbc.url 配置。选驱动需注意特性支持与维护状态。

• ConnectionFactory 创建连接
• Connection 的 createStatement/事务
• Statement 的参数绑定与执行

R2DBC 1.0 规范定义了响应式数据库访问的核心接口。ConnectionFactory 是连接工厂，通过 create() 创建响应式连接（返回 Mono ）。Connection 代表数据库连接，提供 createStatement(sql) 创建 Statement、beginTransaction/commitTransaction/rollbackTransaction 管理事务、close 释放连接。Statement 用于执行 SQL，提供 bind(index, value) 绑定参数、bindNull 绑定空值、add() 添加批量参数、execute() 执行并返回 Flux。Result 包含受影响行数（rowsUpdated）与按列映射的数据。这些接口是响应式的，返回 Mono/Flux，非阻塞。规范还定义了事务、ConnectionFactoryMetadata 等。理解这些接口是掌握 R2DBC 的基础。

三个核心接口构成 R2DBC 骨架：ConnectionFactory 建连接、Connection 管连接与事务、Statement 执行 SQL。全响应式返回 Mono/Flux。是 R2DBC 与 JDBC 的本质区别。

• 同步阻塞 vs 响应式非阻塞
• 连接管理与线程模型
• 返回值类型（Mono/Flux vs 同步）

JDBC 与 R2DBC 的本质差异是"同步阻塞 vs 响应式非阻塞"。JDBC 是同步阻塞 API，数据库操作阻塞当前线程直到结果返回，占用线程（如连接池线程），适合传统 MVC/阻塞模型。R2DBC 是响应式异步 API，数据库操作返回 Mono/Flux，不阻塞线程，通过事件循环/回调处理结果，适合 WebFlux 全栈响应式。差异还包括：连接管理（JDBC 连接池阻塞式，R2DBC 连接池 r2dbc-pool 响应式）、事务（JDBC 用 DataSourceTransactionManager，R2DBC 用 ReactiveTransactionManager）、编程模型（JDBC 同步调用，R2DBC 用 Reactor 操作符组合）。R2DBC 在非阻塞场景吞吐更高，但学习曲线与生态（驱动、工具）不如 JDBC 成熟。

本质差异是"阻塞 vs 非阻塞"。JDBC 同步阻塞占线程，R2DBC 响应式返回 Mono/Flux 不阻塞。由此衍生出连接池、事务、编程模型的差异。选择取决于是否需响应式非阻塞。

• BLOB/CLOB 的二进制/文本大对象
• R2DBC 的 Blob/Clob 抽象
• 响应式读取大对象

R2DBC 处理 BLOB（二进制大对象）与 CLOB（字符大对象）通过 Blob 与 Clob 抽象，它们提供响应式流式读取：Blob 提供 stream() 返回 Flux ，Clob 提供 stream() 返回 Flux，可流式读取大数据而不一次性载入内存。绑定参数时可通过 bind 传入 Blob/Clob 或字节流/字符流。读取时用 Result 的 get 方法按列取 Blob/Clob，再流式消费。响应式 BLOB/CLOB 处理避免大对象占用大量内存，适合存文件、大文本等。注意不同驱动对 BLOB/CLOB 的支持有差异，且需正确释放资源。

R2DBC 的 Blob/Clob 提供流式读取（Flux /Flux），避免大对象一次性载入内存。是响应式处理大数据字段的方式。

• bind 按索引/名称绑定参数
• bindNull 绑定空值及类型
• 参数绑定与执行

R2DBC 的 Statement 通过 bind 方法绑定 SQL 参数：bind(index, value) 按索引绑定，bind(name, value) 按占位符名称绑定（若驱动支持命名参数）。对于 null 值，需用 bindNull(index/name, type) 显式指定类型绑定空值，因为 null 本身没有类型信息，驱动需要知道类型来正确传参。绑定后通过 execute() 执行。多次绑定可用 add() 累积批量参数。正确绑定参数可防止 SQL 注入并保证类型正确。注意不同驱动对命名参数支持不同，索引绑定更通用。

bind 按索引/名称绑定值，bindNull 绑定空值并显式指定类型。参数绑定是 Statement 执行的关键，避免 SQL 注入并保证类型正确。

• execute 执行并返回结果
• query（select）与 update（insert/update/delete）的区分
• Result 的 rowsUpdated 与行映射

R2DBC 中，Statement.execute() 执行 SQL 并返回 Flux。查询（query）与更新（update）通过 SQL 语句类型与 Result 消费方式区分：查询（SELECT）通过 Result 的 map 方法按行映射为对象；更新（INSERT/UPDATE/DELETE）通过 Result 的 rowsUpdated() 获取受影响行数。DatabaseClient 封装了这种区分：sql 后 .fetch() 配合 .all()/one() 取查询结果，或用 .rowsUpdated() 取影响行数。execute/query/update 的边界本质是"SQL 类型 + 结果消费方式"。execute 通用执行，query 取行数据，update 取影响行数。理解边界可正确消费 Result。

边界由 SQL 类型与 Result 消费方式决定。查询用 map 取行，更新用 rowsUpdated 取行数。DatabaseClient 的 fetch 封装不同。execute 是通用入口。

• r2dbc-pool 的 ConnectionPool 配置
• 连接池参数（最大连接、最小空闲、超时）
• 响应式连接获取与释放

r2dbc-pool 是 R2DBC 的响应式连接池，通过 ConnectionPool 与 ConnectionPoolConfiguration 配置。关键参数：maxSize（最大连接数）、initialSize（初始连接）、maxIdleTime（空闲超时）、maxLifeTime（连接生命周期）、maxAcquireTime（获取超时）、maxCreateConnectionTime（创建连接超时）、以及泄漏检测（leakDetection）。连接获取是响应式的（pool.create() 返回 Mono），释放通过 connection.close() 归还连接池。Spring Boot 通过 spring.r2dbc.pool 配置连接池。连接池大小需与数据库连接上限、并发量匹配，避免连接耗尽或过小排队。r2dbc-pool 是 WebFlux 全栈响应式数据库连接池的选择。

r2dbc-pool 提供响应式连接池，配置最大/最小连接、各项超时。连接获取/释放响应式，size 与数据库及并发匹配。是全栈响应式的连接池。

• R2dbcEntityTemplate 的实体操作
• select/insert/update/delete 的 Fluent API
• 与实体映射

R2dbcEntityTemplate 是 Spring Data R2DBC 提供的实体级响应式操作模板，提供 Fluent API 按实体操作，避免手写 SQL。用法：template.select(...).from(Entity.class).matching(...).all() 查询；template.insert(entity) 插入；template.update(entity) 更新；template.delete(entity) 删除。select 支持 Criteria 条件（matching(...)）、where 条件、分页（limit/offset）、排序（orderBy）。R2dbcEntityTemplate 自动处理实体与表的映射（@Table、@Id、@Column 注解）。相比 DatabaseClient，R2dbcEntityTemplate 面向实体、更面向对象，适合 CRUD 操作；DatabaseClient 适合复杂 SQL。它是 R2dbcRepository 的底层实现基础。

R2dbcEntityTemplate 是实体级 Fluent API，select/insert/update/delete 面向实体，支持 Criteria 条件。R2dbcRepository 基于它实现。适合面向对象的 CRUD。

• R2dbcRepository 的接口定义与派生查询
• 响应式 Repository 方法
• 与自定义查询结合

R2dbcRepository 是 Spring Data R2DBC 提供的响应式仓库接口，继承 ReactiveCrudRepository，提供 CRUD 与派生查询方法。工程应用：定义接口继承 R2dbcRepository<Entity, Id>，Spring 自动生成实现；方法名派生查询（如 findByUsername、findByStatusOrderByCreatedAt）自动生成查询；返回 Mono/Flux（响应式）。可用 @Query 注解写自定义查询。R2dbcRepository 与 WebFlux 集成，控制器直接注入 Repository 返回响应式数据。工程最佳实践：实体用 @Table/@Id 注解映射，派生查询遵循命名规范，复杂查询用 @Query 或 DatabaseClient。R2dbcRepository 简化了响应式数据访问层。

R2dbcRepository 继承 ReactiveCrudRepository，提供响应式 CRUD 与派生查询，返回 Mono/Flux。与 WebFlux 集成作为数据层。工程上用于简化响应式数据访问。

• RSocket 在网关/Service Mesh 的定位
• 相比 HTTP/REST 的响应式通信优势
• 背压、单向推送、双向流等痛点

RSocket 在 Service Mesh 与 API 网关场景中定位于"高性能响应式通信协议"，解决 HTTP/REST 在响应式场景的痛点。相比 HTTP/REST，RSocket 解决了：一是应用层背压，HTTP/1.1 无背压，RSocket 提供 request(n) 信用机制，避免内存溢出；二是双向流与单向推送，fire-and-forget 与 channel 支持服务端主动推送与双向流，HTTP/REST 需轮询或 SSE；三是多路复用与连接复用，单连接多路复用减少连接开销；四是长连接高效复用，减少反复握手。在网关/Service Mesh 中，RSocket 用于服务间响应式通信，提供低延迟、背压、流式交互。但 RSocket 生态与服务发现/负载均衡集成不如 HTTP/REST 成熟，需评估。相比 HTTP/REST，RSocket 更适响应式、流式、背压敏感的通信。

RSocket 的定位是"响应式通信协议"，解决 HTTP/REST 的背压缺失、单向推送难、连接复用差等痛点。适用于网关/Service Mesh 的响应式服务间通信，但生态集成需评估。

• RSocket 应用层 request(n) 信用机制
• request-stream/channel 的背压
• 与 TCP 流控（拥塞控制）的区别

RSocket 在应用层实现背压，通过 request(n) 信用机制：订阅者通知发送方"我还能接收 n 个元素"，发送方按信用额度发送，request-stream 与 channel 交互模型都采用该机制控制数据流。这与 TCP 流控（拥塞控制）有本质区别：TCP 流控（滑动窗口、拥塞窗口）针对的是"网络层字节传输"，TCP 无法感知应用层消息边界，背压粒度是字节级、基于网络拥塞；RSocket 的 request(n) 是"应用层消息级"背压，针对的是业务消息数量，发送方按应用语义控制发送，能感知并传播到响应式流水线。RSocket 背压让应用层能控制消息速率，避免消费者过载，与 TCP 的字节级网络流控互补。在 request-stream/channel 中，request(n) 声明可接收的响应/请求数量，实现精细背压。

核心区别是"背压层级"：TCP 流控是网络字节级拥塞控制，RSocket request(n) 是应用层消息级信用背压。后者能感知业务语义并传播到响应式系统。两者互补。

• request-response 请求-响应
• fire-and-forget 即发即弃
• request-stream 请求-流

RSocket 定义四种交互模型：request-response 对应"一对一的请求-响应"，类似传统 RPC/HTTP，客户端发一个请求，服务端返回一个响应，适合常规调用。request-stream 对应"一个请求、多个响应"，客户端发一个请求，服务端持续返回一个数据流，适合分页、事件流、订阅。fire-and-forget 对应"即发即弃"，客户端发请求后不等待响应，适合日志、通知、异步任务触发，最大吞吐。channel 对应"双向流"，客户端与服务端双向持续发送数据流，适合双向交互（如实时双向通信、流媒体）。四种模型覆盖了从单次请求到双向流的通信语义，配合应用层背压实现响应式通信。选择合适的模型可优化吞吐与延迟。

四种模型对应不同通信语义：单请求单响应、单请求多响应、即发即弃、双向流。从简单到复杂，适配不同场景。配合背压实现响应式通信。

• RSocket 帧格式与帧类型
• SETUP 帧的连接建立
• lease 限流（租约）机制

RSocket 通信基于帧（Frame），每种帧类型承载不同语义（SETUP、REQUEST_RESPONSE、REQUEST_STREAM、PAYLOAD、METADATA_PUSH、LEASE 等）。连接建立时，客户端发送 SETUP 帧，包含协议版本、元数据格式、数据格式、keepalive 参数等，服务端校验并建立连接，之后才能进行交互。lease 限流机制：服务端通过 LEASE 帧向客户端发放"租约"，租约指定一段时间内可发送的请求数量（或允许的请求频率），客户端在租约有效期内才能发送请求，用于服务端限流保护（防止客户端过度请求）。lease 机制实现服务端对客户端请求量的控制，是 RSocket 的限流手段。理解帧格式与连接建立、lease 限流是掌握 RSocket 协议的基础。

RSocket 是帧协议，SETUP 帧建立连接，LEASE 帧实现服务端限流。帧承载交互语义，lease 控制请求速率。理解这些是掌握 RSocket 协议与工程实践的基础。

• r2dbc.* 指标（连接池、执行时间）
• 慢 SQL 的观测与监控
• 结合 Micrometer/Actuator

R2DBC 通过 Micrometer 暴露响应式指标，命名空间为 r2dbc.*，包括连接池指标（活跃连接数、空闲连接数、排队等待数、获取连接时间等）与执行指标（SQL 执行次数、耗时、错误率）。Spring Boot Actuator 通过 /actuator/metrics 暴露这些指标，可结合 Prometheus/Grafana 监控。慢 SQL 观测：通过执行耗时指标（如 r2dbc 查询耗时分布）识别慢查询，或使用数据库自身的慢查询日志、以及自定义拦截器记录超阈值 SQL。观测慢 SQL 可定位性能瓶颈，优化索引与查询。响应式指标需注意连接池/执行指标与 WebFlux 请求指标的结合，全面监控数据库性能。

r2dbc.* 指标覆盖连接池与执行性能，通过 Micrometer/Actuator 暴露。慢 SQL 通过耗时指标与慢查询日志观测。结合监控定位数据库性能瓶颈。

• Flyway 的响应式迁移支持
• 与 JDBC 迁移的差异
• 限制与注意

Flyway 从特定版本支持 R2DBC 迁移（r2dbc migration），通过 Flyway 的响应式 API 在响应式环境中执行数据库迁移。Flyway 提供 Flyway#configure(ConnectionFactory) 或通过 R2DBC 连接工厂执行迁移，支持在 WebFlux 应用启动时执行 schema 迁移。限制：一是 R2DBC 迁移不通过 JDBC，需使用 R2DBC 驱动，部分数据库特性（如某些 SQL 方言、事务）支持可能受限；二是响应式迁移 API 与阻塞式 Flyway 使用方式不同，需用响应式 API（如 FluentConfiguration 的 database(ConnectionFactory)）；三是迁移脚本与校验逻辑需兼容 R2DBC 驱动。因此使用 Flyway 做 R2DBC 迁移时需确认驱动与版本支持，并注意与阻塞式迁移的差异。

Flyway 支持 R2DBC 迁移，但通过响应式 API 与 R2DBC 驱动执行，与 JDBC 迁移有差异。限制在于驱动支持、SQL 方言与 API 使用方式。需确认版本与驱动兼容。

• RSocket 与 WebSocket 的定位差异
• 传输层与协议层的关系
• RSocket 构建在 WebSocket/TCP 之上的原因

WebSocket 是传输层协议，提供全双工、持久化的字节流传输，但不规定应用层语义（无消息格式、无背压、无交互模型）。RSocket 是应用层协议，定义交互模型、背压、帧格式等语义，需要依赖传输层（TCP 或 WebSocket）承载其帧。因此 RSocket 构建在 WebSocket/TCP 之上而非替代它们：RSocket 借 WebSocket 的连接能力（浏览器兼容、跨域、代理友好）或 TCP 的可靠传输，在传输层之上提供应用层语义。定位差异：WebSocket 是"传输管道"，RSocket 是"应用协议"。RSocket 复用 WebSocket 的传输（尤其浏览器端），在其上实现背压、多路复用、四种交互模型。所以 RSocket 与 WebSocket 是"协议层叠"关系，不是替代关系。

关键认知："WebSocket 是传输层，RSocket 是应用层"。RSocket 依赖传输层承载帧，故构建在 WebSocket/TCP 之上。WebSocket 提供连接，RSocket 提供语义。二者是层叠而非替代。

• resume 断线重连与会话恢复
• 帧缓存与恢复点
• 流式交互的连续性保证

RSocket 的 resume 机制支持断线重连与会话恢复，保证流式交互的连续性。其核心：连接期间 RSocket 会缓存已发送/接收的帧，并记录恢复点（Resume Token）；断线后，客户端重新连接并携带 Resume Token，服务端根据恢复点从缓存中重放未传输的帧，恢复中断的流，避免从头重发。这一机制对长连接、流式交互（request-stream、channel）尤其重要，能保证断线后数据不丢失、流不中断。实现需配置 resume 选项（resume() 启用、缓存大小、超时）。配合 keepalive 与缓存，RSocket 在传输层断开时仍能保持应用层会话的连续性。注意恢复窗口与缓存大小需权衡内存。

resume 通过 Resume Token + 帧缓存实现会话恢复，断线后从恢复点重放帧，保证流式连续性。对长连接尤为重要，需权衡缓存内存。

• @MessageMapping 暴露 RSocket 端点
• RSocketRequester 发起调用
• 与 WebFlux 的整合

Spring 中通过 @Controller + @MessageMapping 暴露 RSocket 端点，类似 WebSocket 消息映射，方法返回 Mono/Flux（响应式）。客户端用 RSocketRequester 发起调用：RSocketRequester.builder().tcp(...) 或 .websocket(...) 建立连接，然后 .route("route").data(payload).retrieveMono()/retrieveFlux()/send() 对应四种交互模型。与 WebFlux 整合：RSocket 与 WebFlux 共享响应式模型（Reactor），Spring 的 RSocket 支持基于 WebFlux 的响应式基础设施，控制器方法返回 Mono/Flux。整合时，RSocket 端点与 WebFlux 端点可共存，接收方用 @MessageMapping 处理，发送方用 RSocketRequester。RSocket 与 WebFlux 的响应式模型一致，实现无缝整合。

服务端用 @MessageMapping 暴露 RSocket 端点，客户端用 RSocketRequester 调用。两者共享 Reactor 响应式模型，与 WebFlux 无缝整合。RSocket 是 WebFlux 生态的通信协议。

• RSocket Routing 的负载均衡与服务发现
• 与 Spring Cloud 的集成
• 集成现状与局限

RSocket Routing 扩展用于在 RSocket 连接上实现路由与负载均衡：通过 broker（如 RSocket Broker）将请求路由到多个服务实例，结合服务发现（如注册中心）进行负载均衡。RSocket 的负载均衡与传统 HTTP 不同，它是"连接级"（连接建立后多路复用），需在连接层做路由。Spring Cloud 中，RSocket 的服务发现与负载均衡集成（如与 Spring Cloud LoadBalancer、Eureka/Nacos 结合）尚不成熟，不像 HTTP/OpenFeign 有成熟方案。集成分现状：Spring Cloud 对 RSocket 的支持有限，更多是实验性或社区方案，需要自定义 broker 或负载均衡逻辑。因此使用 RSocket Routing 结合服务发现需要额外设计与实现，评估其复杂度与生态成熟度。

RSocket Routing 做连接级路由与负载均衡，需结合服务发现。难点在于 RSocket 是连接级多路复用，负载均衡与传统 HTTP 不同。Spring Cloud 对 RSocket 的集成尚不够成熟，需自定义。

• r2dbc-h2 内存数据库测试
• Testcontainers 的容器化数据库测试
• 响应式数据层测试流程

响应式数据层测试可结合 r2dbc-h2 与 Testcontainers。r2dbc-h2 是 H2 内存数据库的 R2DBC 驱动，用于快速、轻量的单元/集成测试（无需真实数据库）；Testcontainers 则启动真实数据库容器（如 MySQL/PostgreSQL 容器），进行更真实的环境测试。流程：用 r2dbc-h2 配置测试环境的 ConnectionFactory（spring.r2dbc.url=r2dbc:h2:mem:///test 等），配合 Spring Boot 测试自动配置；或用 Testcontainers 启动数据库容器，动态配置 R2DBC URL。测试中验证 Repository/DatabaseClient 的响应式操作（用 StepVerifier 断言 Mono/Flux），可用 Flyway 或 schema.sql 初始化表。r2dbc-h2 侧重快速，Testcontainers 侧重真实兼容性，两者结合覆盖不同测试需求。

r2dbc-h2 提供轻量内存数据库测试，Testcontainers 提供真实数据库容器测试。结合 StepVerifier 验证响应式数据层。按需选择轻量或真实环境。