本文详解为何在使用 flatMap 递归调用 deleteAccount() 时导致下游服务方法被意外触发两次，并指出根本原因在于测试中对 Mono.block() 的重复调用，而非 flatMap 本身逻辑错误；同时提供基于 StepVerifier 的规范测试方案与代码改进建议。
本文详解为何在使用 `flatmap` 递归调用 `deleteaccount()` 时导致下游服务方法被意外触发 twice，并指出根本原因在于测试中对 `mono.block()` 的重复调用，而非 `flatmap` 本身逻辑错误；同时提供基于 `stepverifier` 的规范测试方案与代码改进建议。
在使用 Project Reactor 编写响应式服务逻辑时，一个常见误区是将阻塞式测试习惯带入异步流验证中。您遇到的 accountRegistry.getSessions() 被调用两次的问题，并非源于 flatMap 的“重复订阅”或递归逻辑缺陷，而是测试代码中对同一 Mono 实例连续调用了两次 .block()：
var res = sut.deleteAccount(accountId); assertEquals(res.block().getDeletedSessions().contains(accountId)); // ← 第一次 block() → 触发完整链路执行 assertEquals(1, res.block().getDeletedSessions().size()); // ← 第二次 block() → 再次触发完整链路执行！
由于 Mono 是冷序列（cold publisher），每次 block() 都会重新订阅并重放整个数据流 —— 包括 accountDataProvider.accountDataFor(accountId)、条件判断，以及最终对 accountRegistry.getSessions() 的调用。因此，即使 flatMap 写法完全正确，测试本身已构成双重副作用。
✅ 正确做法：始终使用 StepVerifier 进行响应式流断言，它仅订阅一次，并支持对事件流（onNext/onComplete/onError）进行精确校验：
@Test
void deleteAccount_whenActive_shouldDeleteAndReturnResponse() {
String accountId = "test-123";
StepVerifier.create(sut.deleteAccount(accountId))
.expectNextMatches(response ->
response.getDeletedSessions().contains(accountId) &&
response.getDeletedSessions().size() == 1)
.verifyComplete();
// 单次验证，单次订阅
verify(accountRegistry).getSessions(eq(List.of(accountId)));
}⚠️ 补充注意事项：
-
禁止在测试/生产中对同一
Mono多次调用block()：这违背响应式编程原则，且极易引发重复副作用（如重复 DB 写入、HTTP 调用、消息发送等）。 -
flatMap本身不会导致“重复执行”——它只是将内部Mono扁平化接入当前流；递归调用deleteAccount(accountId)在逻辑上是合法的，但需确保终止条件明确（例如避免无限循环），当前代码中isActive == false时返回Mono.just(new Response())已满足终止。 - 若需调试流执行路径，可添加
.doOnNext()或.log()，而非依赖block()：
return accountDataProvider.accountDataFor(accountId)
.doOnNext(data -> log.info("Fetched account data: {}", data))
.flatMap(accountData -> {
if (accountData.isActive) {
return deleteAccount(accountId); // 递归调用，注意栈深度与背压（实际中建议改用循环或状态机）
}
return Mono.just(new Response());
});总结：Reactor 的核心契约是「每个订阅产生独立执行」。测试阶段必须恪守这一原则——用 StepVerifier 替代 block()，既保障语义正确性，也避免隐蔽的重复副作用。将阻塞式思维切换为声明式验证，是写出健壮响应式代码的第一步。
