flaky 用例：当场重试救火，还是拉黑等修？想听大家的取舍

背景

做了 3 年接口自动化（pytest + httpx，套件 2000+ 条，跑在多人共享的 staging 上），我最怕的不是"用例红了"，而是"红的里面有几条是真的"。flaky 用例是自动化套件的头号天敌：它不报错，它只是间歇性地报错——你没法相信绿色的全绿，也没法相信红色的全红。

最近一次统计：过去 3 个月 CI 里 12% 的失败最终被确认为 flaky（超时、并发顺序、共享数据、环境抖动），但发现一条 flaky 平均要 2 天（因为它不连续复现）。团队里对 flaky 的处理方式一直没人统一，每次都是谁撞见谁处理。

常见分歧（我观察到的三种做法）

1. 当场重试派：pytest-rerunfailures 一把梭，失败重试 2 次，绿了就当没事。优点：CI 不红、不阻塞发布、开发不烦。缺点：flaky 被"绿"掩盖，永远没人修；而且重试会放大副作用（重复下单、脏数据），我踩过一次重试把测试数据插了 3 遍，下游报表对不上。
2. 拉黑隔离派：一发现 flaky 立刻 @pytest.mark.skip 或 xfail，挂个 issue 等修，修好再放开。优点：诚实，CI 状态可信；缺点：skip 清单常年没人清，我见过一份 skip 列表挂了 14 个月，最后连是谁 skip 的都忘了。
3. 门禁阻断派：flaky 出现一次就 fail 整个流水线，强制当周修完。优点：压力最大、修得最勤；缺点：一条 flaky 卡住所有人的发布，而且"修 flaky"常常要动环境或后端，测试同学根本修不动，最后演变成扯皮。

我的倾向

我倾向**"拉黑隔离 + 数据驱动复活"**的混合，但有三条硬规则：

1. 重试最多 1 次，且重试结果单独标记（报告里区分"首次失败-重试通过"和"稳定通过"），绝不悄悄变绿；
2. skip 必须带三要素：谁 skip 的、疑似根因、预计复活时间，缺一不许合入；
3. 每月一次"skip 复活日"：把超过 1 个月没复活的 skip 用例批量重跑，仍 flaky 的直接退役（不是继续挂着）。 核心原则：flaky 不是"环境问题"，是"工程债务"——它要么被量化、要么被偿还，不能只是被跳过。

想听大家

• 你们团队对"重试通过"算通过还是算失败？有没有在报告里做区分？
• skip 列表有没有人管？怎么防止变成垃圾场？
• 你们遇到过最顽固的一条 flaky 是什么根因？最后怎么收场的？