本文详解 Flux.repeatWhen 在条件为假时因默认无上限重试导致测试无限等待的问题，介绍通过 repeatMax() 限制重试次数、结合 exponentialBackoff 构建可控的轮询逻辑，并提供可验证的测试方案。
本文详解 `flux.repeatwhen` 在条件为假时因默认无上限重试导致测试无限等待的问题，介绍通过 `repeatmax()` 限制重试次数、结合 `exponentialbackoff` 构建可控的轮询逻辑，并提供可验证的测试方案。
在响应式编程中，使用 Flux.repeatWhen 实现基于动态条件（如特征开关）的周期性轮询是一种常见需求。但若未显式限制重试次数，Repeat.onlyIf 的默认行为会以 Long.MAX_VALUE 次尝试无限重试——即使条件始终为 false，也会持续触发退避调度，导致 StepVerifier 无法正常终止。
你原始代码的核心问题在于：
.repeatWhen(Repeat.onlyIf(context -> !isEnabled())
.exponentialBackoff(Duration.ofSeconds(1), Duration.ofSeconds(5)))
该配置虽启用了指数退避，但未设置最大重试次数，因此当 isEnabled() 始终返回 false 时，repeatWhen 将无限期地生成新的订阅，而 StepVerifier.thenCancel() 仅取消当前订阅流，无法中断后台正在排队的后续重试任务（它们由 Schedulers.parallel() 等默认调度器异步触发）。
✅ 正确做法是显式调用 repeatMax(n) 来限定总重试次数：
public Flux<string> getData(String request) {
return Flux.just(request)
// 条件为真：直接重复（无延迟）
.repeatWhen(Repeat.onlyIf(context -> isEnabled()))
// 条件为假：指数退避 + 最多重试3次
.repeatWhen(Repeat.onlyIf(context -> !isEnabled())
.exponentialBackoff(Duration.ofSeconds(1), Duration.ofSeconds(5))
.repeatMax(3)) // ? 关键：防止无限循环
.flatMap(this::process)
.retry(); // 处理下游异常的重试（与 repeatWhen 分离）
}</string>
? 注意：repeatMax(3) 表示 最多再执行3次重试（即原始流 + 最多3次重复 = 总共4次发射），而非“总共只运行3次”。若需严格控制总轮询次数，建议统一用单个 repeatWhen 配合自定义逻辑，或改用 Flux.generate() + delayUntil()。
? 测试时务必使用 虚拟时间（Virtual Time） 并覆盖重试边界：
@Test
void testDisabledFeatureFlag_StopsAfterMaxRetries() {
// 模拟 isEnabled() 始终返回 false
when(featureFlagService.isEnabled()).thenReturn(false);
StepVerifier.withVirtualTime(() -> getData("req"))
.expectSubscription()
.thenAwait(Duration.ofSeconds(10)) // 足够覆盖 1s→2s→4s ≈ 7s 退避总和
.expectNextCount(0) // 无任何元素发出
.verifyComplete(); // ✅ 验证正常完成（非 cancel 或 timeout）
}
⚠️ 关键注意事项：
- thenCancel() 对无限 repeatWhen 无效，应优先用 verifyComplete() 配合 repeatMax；
- exponentialBackoff 的第二个参数是最大间隔（非总超时），实际等待时间为各次间隔之和；
- 若需更精细控制（如根据错误类型分流重试），建议组合 onErrorResume + delayUntil 替代嵌套 repeatWhen；
- 生产环境务必设置合理的 repeatMax 和 maxDelay，避免资源耗尽。
通过明确约束重试边界，你的轮询逻辑将既健壮又可测——不再“永不终止”，而是“按需可控”。
