幂等性测试：服务端已执行成功但响应在途中丢失，重试时怎么断言「第一次真的执行了」？「响应丢失」场景怎么造才不 flaky？

【背景】 3 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3.2 + MySQL 8.0.34），接口自动化 pytest 7.4 + httpx 约 900 条用例，跑在 5 人共享 staging（MySQL 8.0 + Redis 7.2，GitLab CI）。团队已按社区经验给写接口加了幂等键（客户端生成 UUID，服务端幂等表唯一索引 + 状态机），设计侧参考过 id=1562（幂等三件套）和 id=1884（状态机语义），并发竞态的用例参考 id=697（线程池 + 乐观锁版本号）也写了一版。

但过去半年我复盘了 3 起线上问题，共同点是：幂等设计本身没 bug，是我们的测试从来没真正验证过「客户端超时 → 重试」这条路径。幂等测试用例目前只有「同一幂等键连发两次，断言第二次返回 409 + 状态不变」——这只能覆盖「请求都正常到达」的场景，覆盖不到真正致命的场景：

【现象 / 卡点】

1. 最致命场景测不到：客户端发请求 → 服务端执行成功（写库 + 扣款）→ 响应在回传途中超时/丢失 → 客户端收到 timeout → 重试。这时服务端幂等表里已有第一次记录，应该返回「幂等命中 + 原始结果」。但我们的测试根本没法区分「第一次请求真的执行了」和「第一次请求根本没到」——从客户端视角两者都是 timeout，断言无从下手；
2. 幂等命中后的响应语义断言不了：幂等命中时服务端到底该返回什么？200 + 原始响应体？409 + 原始响应体？还是 200 + 一个「这是幂等命中，结果在 body 里」的标志位？社区里 id=1884 讨论了状态机设计，但测试侧到底断言什么才算「幂等拦截正确」，我还没看到正面回答——不同团队语义不一致，用例没法写通用断言；
3. 「响应丢失」的造法要么不可控要么 flaky：
   • toxiproxy 加 timeout toxic（服务端处理完但响应不回传）：理论可行，但 toxic 的生效窗口（请求到达后多久开始丢弃响应）我调不准，用例偶发「第一次请求被 toxic 直接 drop 掉、根本没执行」，红了又绿，和我们治理 flaky 的投入直接冲突；
   • 客户端侧 mock server sleep 后不返回：只能测「超时后客户端行为」，测不了「服务端已执行」这一半；
   • 直连 MySQL 查库断言「第一次执行了」：能断言，但依赖时序（重试请求查库时第一次的事务可能还没 commit），flaky；
4. 幂等窗口过期后的行为没人测：id=1562 提到幂等窗口（如 7 天），窗口过期后同一幂等键再来，是「当新请求执行」还是「报错」？这个行为我们完全没测过，线上有没有人踩过不知道。

【已尝试的排查与结果】

• 在 toxiproxy 里用 bandwidth toxic 把响应带宽压到极低（如 10KB/s），配合客户端 500ms 超时：能稳定触发「服务端执行完 + 客户端超时」，但用例耗时从 0.3s 涨到 3s+，且对 runner 负载敏感（4C8G 上偶发第 2 次请求也超时），flaky 率 ~8%；
• 在测试 profile 里把幂等表 TTL 调短（如 10s），专门测「窗口过期后重发」：能测，但和生产 TTL（7 天）差 5 个数量级，「TTL 判断逻辑」在不同 TTL 下行为可能不一致（比如边界条件、时钟漂移），不敢直接下结论说测到了；
• 给幂等命中的断言加「查库 + 查响应」双重验证：有效，但查库时序问题如上，且让用例依赖了 DB 连接池（staging 共享，偶尔连接池满，flaky）；
• 翻过 id=697 的并发竞态套路（线程池 + 幂等键 + 乐观锁），确认它测的是「同一时刻多个请求」，不是「同一请求超时后重发」，两条路径的失败模式不同，不能直接复用。

【期望得到的答案形态】

1. 一个可复现的「响应丢失」测试姿势：能稳定触发「服务端已执行成功 + 客户端收到超时」，但不依赖时序窗口（最好给出 toxiproxy 配置片段或 mock server 代码），且用例耗时可控（≤2s）、对 runner 负载不敏感；
2. 幂等命中后的断言清单：服务端返回什么状态码、响应体里哪些字段是「幂等命中的标志」、哪些字段应该和第一次完全一致、哪些字段允许不同（如 traceId）——想听不同团队的语义约定，以及为什么这么约定；
3. 幂等窗口过期后的行为：有没有团队测过「TTL 过期后同一幂等键重发」？是当新请求执行、还是返回明确错误？测试侧怎么在不改生产 TTL 的前提下覆盖这个分支？
4. 如果社区有现成的「幂等性测试用例模板」（覆盖：并发重复、超时重发、乱序重试、幂等键复用但参数不同、窗口过期 5 个场景），直接贴一份能抄的样例。

我目前的倾向是「toxiproxy timeout toxic + 服务端主动标记『已执行』到 Redis（带 TTL）+ 测试侧断言 Redis 标记 + 查库」的组合，但「服务端主动标记」这个方案在生产环境有没有副作用（比如标记和写库不在同一事务里，标记成功但写库失败），我还没想清楚，想先听听大家踩过的坑。