CI 里怎么测「超时后按指数退避重试 2 次」这条路径，不真等 2 秒、也不靠 mock 时钟绕过被测代码？

【背景】 我在一条支付链路上做接口自动化（Java 17 + Spring Boot 3 + JUnit 5 + Resilience4j，CI 用 GitLab Runner，2 台 4C8G 并行）。被测服务对下游风控接口的调用策略是：timeout=500ms、maxAttempts=3（首次 + 重试 2 次）、指数退避（100ms 起步、factor 2）。社区里《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》(id=23) 把这组参数讲成「容量规划的一部分」，多下游预算切分也有讨论(id=527)——但站在测试侧，这条「超时→退避→重试→最终失败」的路径在 CI 里到底怎么测，我还没看到正面回答，这也是我卡住的地方。

【现象 / 卡点】

1. 真实等待：让下游 mock server sleep 600ms 再返回，一次完整断言就要 500ms×3 + 100ms+200ms 退避 ≈ 2.1s；这条链路有 14 个类似的超时分支用例，全跑一遍 ≈ 30s，且每次失败都发生在超时边界附近，在 4C8G 的 runner 上偶发「第 3 次重试没在超时窗口内发出」，红了又绿、绿了又红——典型的 flaky，和我们治理 flaky 用例的投入直接冲突。
2. 纯 mock 时钟：用 Mockito 把 Clock/System.currentTimeMillis 替换掉后，超时判定和退避间隔都「瞬间走完」，用例全绿——但这条路径里最该被测的两段（超时判定、重试调度）恰好被我 mock 掉了，等于没测。
3. 故障注入：想到用 WireMock 的 fixedDelay / 故障注入（如 Chaos Toolkit）让下游可控地慢/丢包，但每次注入都要单独起一个故障策略 + 清理，14 个用例写下来配置比被测代码还多，团队没人愿意接手维护。

【已尝试的排查与结果】

• 把超时从 500ms 调到 50ms 加快测试：CI 变快了，但「第 3 次重试是否发出」对调度延迟更敏感，flaky 率反而从 ~5% 升到 ~12%；
• 在测试 profile 里把 maxAttempts 调成 1：能测「超时会失败」，测不了「重试 2 次后仍失败才走降级」，断言覆盖不到重试计数与退避序列；
• 给用例加 3 次自动重试救火：治标，且让 flaky 统计被自己稀释了；
• 翻过 Resilience4j 官方文档，确认它支持注入 TimeLimiter 与 Clock，但「注入虚拟时钟后，超时判定本身是否还走真实的 ScheduledExecutorService」这条链路没有写清楚，我不敢直接下结论。

【期望得到的答案形态】

1. 一个可复现的测试姿势：能真实执行「超时→退避→重试→降级」全路径，但用例耗时控制在 1s 以内、且对 runner 负载不敏感（最好给出配置片段）；
2. 对「虚拟时钟 vs 缩短真实超时 vs 故障注入」三种方案，各自测到了什么、漏掉了什么的明确边界（比如虚拟时钟测不了真实调度线程的超时精度）；
3. 如果社区有现成的故障注入模板（WireMock fault / toxiproxy / 自研 mock server 的慢响应端点），直接贴一份能抄的样例。

我倾向于「可控慢响应的 mock server + 生产参数不变 + 超时预算单独可注入」的组合，但没验证过退避序列的断言怎么写才不 flaky，想先听听大家踩过的坑。