测试数据：避免测试环境生成生产账号的方法

测试环境为了做一次检查而临时连上了生产服务，之后却没人切回去。一个月后，一次自动化运行在生产服务上生成了十几个真实账号，支付网关还为一笔试跑订单扣了真金白银。事故的根源不在这次运行本身，而在于两边从配置层面就没有分开。下面拆解这类事故是怎么发生的，以及运行前该检查什么。

典型事故：一次运行如何生成生产账号

场景几乎千篇一律：环境配置是从生产环境复制过来的，改了一部分参数，却漏改了 API 地址或访问密钥。运行一连几个月都没出问题——直到某一次恰好碰到注册或支付接口。这时生产数据库里就会出现名字像 test_user_1 这样的真实账号，支付网关也会为试跑订单产生真实扣款。

更糟的是事故没有被及时发现：这些账号会在生产环境里存在数周，被计入统计分析，扭曲转化率指标，排查事故时还会和真实用户混在一起。

不依赖人工记忆的可靠办法，是把配置物理拆分开：两边各自有一套访问密钥、各自的 API 地址、各自的回调域名。用一份配置文件加一个「测试/生产」开关来切换，是大多数事故的根源，因为部署时这个开关很容易被忘记切换或者切错方向。

密钥的格式建议对照文档核实——比如号码租用 API 文档：测试密钥和生产密钥外观上往往几乎一样，区别只能从前缀或密钥所属的后台板块上看出来。

自动化运行需要真实的号码和邮箱，否则无法验证短信接收或确认邮件。常见的错误是直接从共用的生产资源池里取用：被占用的号码会退出正常销售，运行结束后还可能一直绑定在一个原本没人打算创建的账号上。

正确做法是单独准备一个资源池，在分配阶段就打上专门的标记，并为它建一份独立台账：字段和生产资源一样——所属环境、日期、状态——但状态值单独标为「测试」。这类台账整体如何搭建，参见号码、邮箱和 IP 的资产盘点一文。

每次发布配置前值得检查几个信号：环境日志里出现了生产域名，或者出现了来自API 轮换池的生产地址；生产环境的统计数字随着这次运行同步上涨；客服的生产邮箱收到了带测试名称的自动回复；生产钱包余额在没有任何人工操作的情况下下降，而此时本应只有一次试跑在进行。

出现其中任何一个信号，都应立即停止运行，而不是给流程加一条「在生产环境里忽略」的例外。

最可靠的原则比任何监控都简单：测试环境的访问密钥物理上不能存在于生产环境里，生产密钥也不能存在于测试环境里。不是「默认关闭」，而是根本不存在——这样一来，方向错误的调用会直接因鉴权失败而中断，不会真的打到生产服务上。

第一次自动化运行之前，需要确认四件事：测试环境配置里的 API 地址和访问密钥不是从生产环境直接复制来的；本次运行用的号码与邮箱池是单独的，并打上了对应标记；操作次数设有上限，避免错误在被发现之前扩散成上百次请求；运行日志能立即查看，而不是只能靠事后手动申请。

发起一次特征明显的调用——比如创建一个带唯一名称的资源——然后查看它是否出现在生产后台。如果出现了，说明配置搞混了。

不建议：哪怕运行时间很短，也会占用生产资源池里的一个号码，一旦清理环节出问题，这个号码就无法按时回到正常销售中。

按识别特征——名称前缀或明显偏离正常流量的创建时间——把它们筛出来，手动删除或停用，然后彻底解决根源：共用的密钥或共用的 API 地址。

如果需要一批独立的真实号码和邮箱用于测试，又不想触碰生产数据，号码与邮箱租用板块支持按个分配资源，默认不会与其他环境产生交叉。