测试数据清理：「teardown 全绿」到底算不算证据？你们把 DB 回到基线的校验放在哪一层？

【背景】 我做了 10 年测试开发，带过 3 拨团队，见过最离谱的一次事故：共享 staging 环境，一次回归跑完 2000 条用例，所有 fixture 的 teardown 都是绿的，但第二天另一个小组的接口测试全挂了——查下来是上一轮有个用例在 teardown 里抛了异常被 catch 后吞掉，往订单表里留了 3 万多条脏数据，其中 12 条恰好命中了对方风控规则的边界值。 从那以后我给自己立了条规矩：teardown 返回成功，只证明「清理代码没报错」，不证明「数据库回到了基线」。这两件事在工程上完全是两个命题，就像你锁了门不等于家里没人。

【常见的几种做法，也是分歧所在】

1. 「信任 teardown」派：每条用例自带清理，CI 里不额外校验。优点是快，代价是上面这种静默污染，而且共享环境里你根本不知道谁污染了谁。
2. 「跑完全量 diff」派：环境维护一份基线快照，跑完用例后逐表 diff。彻底，但 2000 条用例跑完再 diff 一次，宽表动辄几十万行，动辄几分钟甚至十几分钟，门禁拖到没人愿意等，最后就变成「跑挂了再说」。
3. 「计数 + 抽样」派：跑完只查各表 count 和几个关键字段的 max/min 分布。快，但脏数据如果正好把 count 补平了（比如删了 100 条又插了 100 条），就漏了。
4. 「环境隔离」派：干脆不用共享 staging，每个流水线给独立环境。最干净，但成本高，而且很多团队根本没有这个预算。

【我的倾向与理由】 我倾向「分层门禁」：把「清干净了没有」拆成两个不同强度的问题。

• 快速门禁（10 秒内）：只校验「增量」。跑用例前记一份轻量基线——每张关心的表的 count、自增主键的 max、以及一个业务唯一键的 count（比如订单号前缀 + 日期维度）。跑完后只对比这几组数字，差异非零就直接红。它不追求 100% 覆盖，追求的是「95% 的污染在 10 秒内被抓到」。
• 深度校验（异步，不阻塞门禁）：对增量区间做行级 diff（按主键 max 圈定新写入的区间），结果落盘，第二天看报告。这样门禁不拖，但污染不会静默过夜。 核心逻辑是：门禁只回答「能不能放行」，报告回答「谁污染了环境」，两者职责分开。把深度校验塞进门禁，等于让安检口去做海关查验，队伍就排起来了。

【想听大家在什么场景下怎么选】

1. 你们的共享 staging 上，「teardown 全绿但数据没清干净」发生过几次？怎么发现的？
2. 快速门禁的基线粒度你们怎么取——只 count 够用，还是必须带业务维度？
3. 2000 条用例这个量级，你们有没有人真把行级 diff 做进过门禁？拖了多久，最后是被谁砍掉的？
4. 如果给不出 10 秒门禁，你们退一步的方案是什么——比如只在「跑全量回归后」做一次基线校验，平时不管？ 欢迎贴具体的表结构量级和耗时数据，空对空的方案讨论我一般不参与。