测试数据到底该怎么管：造数、隔离、清理，三种路线你们怎么选？

先讲个我亲历的"血案"：某次回归，一条自动化造了 2 万条订单流水，测试库和生产库共用同一个主从集群（当时为了省事），造数那条事务因为断言失败中途没回滚，结果从库上的报表任务直接把这 2 万条"假订单"算进了当天的 GMV 大盘，值班同学对着曲线发呆了一小时才反应过来。从那以后我对"测试数据"这四个字就格外敏感——它不像功能代码，写错了会报错；它写错了，往往是"静默地"把别的团队、别的环境、别的人的判断污染了。

所以我想把"测试数据怎么管"这个老生常谈摊开聊一次。我发现团队里常见三种路线，各有拥趸：

路线一：专用测试环境 + 定期清库。 造数随意，跑完 truncate 一把。优点是边界清晰、心理负担小；缺点是环境一旦变多（dev/staging/perf），清库脚本本身就成了要维护的"代码"，而且并发跑自动化时，A 用例的清理可能正好踩到 B 用例正在跑的中间态——我见过凌晨跑批，两个团队互删数据的"惨案"。

路线二：数据隔离 + 用例级清理（造数用唯一前缀/租户 id，finally 里删）。 听起来最"工程化"，但现实是：跨服务的测试，你的 finally 里删了 A 服务的数据，B 服务那条关联记录没删，留下一堆"孤儿"；而且清理本身也可能失败，失败了你又得写清理的清理。

路线三：数据工厂 + 快照回滚（或至少是"只读基线 + 增量造数"）。 基线数据保证业务链路能跑通，增量数据每次唯一、可追溯。这套最重，需要有人专门维护"基线是什么、增量怎么造"的契约。

我的倾向：对"接口自动化"用路线二（唯一前缀 + 用例级清理 + 清理失败告警），对"全链路/性能测试"用路线三（基线快照 + 增量），对"临时调试"用路线一但必须走一个"造数审批 + 自动 TTL"的兜底。但我也清楚，这三条路线背后其实是"团队协作成本"和"数据准确性"的权衡，没有标准答案。

想听大家聊几个具体的：

1. 你现在团队是几条路线混着用的？分界点定在哪（用例数？服务数？数据量？）？
2. 清理失败你们怎么处理——重试、告警、还是"算了下次清"？
3. 有没有人踩过"造数代码本身成为维护负担"的坑（比如造数脚本三年没人敢动）？
4. 跨服务测试，你们怎么保证"我删我的、不删你的"？是靠命名约定、租户隔离、还是干脆不删只靠 TTL？

抛砖引玉，欢迎拍砖。