pytest-xdist 并发下"跨用例隐形状态依赖"怎么系统性找出来？

背景 我在一家 B 端 SaaS 团队负责接口自动化（Python 3.11 + pytest 7.4 + httpx 0.25，约 800 条用例），后端 Spring Boot 3 + MySQL 8 + Redis 7 + RocketMQ，CI 是 GitLab Runner 4 并发跑 pytest-xdist（--dist loadscope）。每天夜间全量回归稳定有 5–8 条红，同一套用例在本地顺序执行 10 次全绿。

现象 / 卡点 这些红的用例有个共同特征——不是"脏数据"，而是服务端的"内存态 / 进程态"被前面的用例污染了：

1. 用例 X 挂了，因为前面某条用例把 Sentinel 限流计数器打满了，Sentinel 的滑动窗口还没过期，X 就吃了 429；
2. 用例 Y 挂了，因为前面某条用例把某个 feature flag 从 off 切到 on，但没人切回来，Y 走的是新分支；
3. 用例 Z 挂了，因为前面某条用例在 Redis 里塞了一个 warm_cache:* 的 key，Z 断言的是"冷启动"路径，结果命中了热缓存；
4. 最魔幻的一条：某条用例在 gw-2 worker 上挂、在 gw-1 上绿，我怀疑是测试服务进程内的线程池 / 连接池被前面的压测用例打成了"半死"状态，但日志里完全看不出来。

已尝试 & 结果

• pytest-randomly 打乱顺序：红的用例会"换人"，但数量不变——说明不是固定某条用例的问题，是用例之间的隐形依赖；
• --dist loadfile：把同文件的用例锁在同一个 worker，红的用例数量没变，说明依赖不是文件级的；
• 每条用例 try/finally 清理 Redis / feature flag / 限流计数器：只能清"我知道的"，清不掉"我不知道的"，红的从 8 条降到 4 条，剩下的还是抓不到根因；
• 让测试服务"每条用例前重启"：能治，但 800 条用例 × 15s 冷启动 = 3 小时，CI 成本直接爆炸。

期望得到的答案形态 想听大家可落地的做法（命令 / 配置 / 目录结构都行），特别希望覆盖：

1. 有没有一种系统性的"状态审计"手段，能在每条用例前后对测试服务做一次"快照 diff"（Redis keys 集合 + feature flag 表 + 限流器计数器 + 关键日志区间），把"谁污染了谁"自动标出来？
2. 对于"我不知道的"内存态（线程池、连接池、JVM 堆内对象），有没有轻量级的探针或 sidecar 能在 CI 里低成本采到？
3. 你们团队是怎么给"测试服务"定义一份**"干净状态基线"**的？是每次用例前做一份、还是每天回归前做一份、还是按"污染等级"分级处理？
4. 有没有人真的把"重启测试服务"做成了秒级（比如 JVM 的 --shareclasses + CDS + 预热脚本，或者容器化 + 镜像预拉）？成本大概多少？

欢迎贴你司的 CI job 片段、sidecar 配置、或者踩过的坑。先谢过。