catch-all 邮箱：预发环境为什么要一个全收地址

catch-all 邮箱指的是「无论收件人前缀写什么，信都进同一个信箱」的全收地址。预发环境里它很省事：不用为每个用例建号，任意前缀都能用。但它也有代价，而且代价不小——收件量失控、可能收进真实用户邮件、配置不当时内部邮件也会跟着出去。

全收地址解决的是什么问题

预发环境最常见的需求是「注册流程要能跑通」。如果每跑一次都要人工建一个信箱，测试根本快不起来。全收地址把这一步省掉：地址前缀可以随手写，信一律落到同一个收件箱里，测试只需要读那一个地方。

它还顺带解决了前缀不可控的问题。有些被测系统会自动生成前缀，或者把地址规范化成别的写法；全收模式下，这些不确定性都不再影响能不能收到信。

对只想尽快把流程跑完的团队来说，这个诱惑很大。真正需要判断的是：省下的这点建号工作，值不值得接受后面几项代价。

第二行是自动化里最常见的痛点：共享信箱意味着「取最新一封」这种解析方式迟早会取错，而错误出现在断言环节时，看起来就像是功能坏了。

第三行则是合规与安全事故的分界线：预发环境通常权限更宽、日志更随意，真实用户邮件一旦进去，清理起来非常麻烦，而且很难证明已经清干净。

多半是路由或域名复用造成的。一种情况是把预发域名真的写进了对外可用的入口；另一种是生产与预发的配置互相覆盖，结果发往生产的信被预发的收信服务接走。

还有一种是「把流量导到预发」的排查做法：为了复现线上问题，把一部分真实流量切到预发环境。这在排查时很方便，但如果不把流入范围限定清楚，收件箱就会开始累积真实用户的邮件。

一条不能退让的底线是：预发环境不应该收走生产环境的真实用户邮件。发现这种情况时要当作事故处理，先切断路由，再清理数据，而不是继续拿它做测试。这条底线应该写进环境配置的检查项，而不是靠值班的人记得。

如果你只是需要「一个能收信的地址」，而不需要全收的能力，打开临时邮箱生成一个地址就够用：每个用例一个新地址，天然带着归属信息，不需要维护任何前缀规则，也不会把别人的邮件收进来。

它的取舍正好相反：收信范围窄，所以信箱不会变浑；代价是地址要自己管理。对多数测试来说，这比维护一个全收地址更省心，因为再也没有「这封信是给谁的」这类问题。

全收只应该开在明确的环境里，最好做成一个可以随时关掉的开关。开启时要同时定义范围：只接哪些域名、哪些前缀，以及哪些来源一律拒绝。范围写得越具体，失控的概率越低。

分流靠前缀：用例自己在地址里写进标识，收信侧按标识分配，这样即使共用同一个信箱，也能确定每封信属于谁。保留策略要写下来，包括保留多久、什么时候清理、清理前是否需要留档。

同时给预发环境的收件箱设一个上限，超过就报警，而不是让它无限增长。相关取舍可以对照临时邮箱和别名的区别与在持续集成里捕获邮件。

全收不是唯一解，先看看有没有更省事的替代。第一种是「每个用例一个临时地址」：地址自己带着归属信息，不需要维护前缀规则，也不会把别人的邮件收进来，代价只是每次都要生成一个新地址。第二种是「按用例分配固定前缀」，也就是在共享信箱上人为划出命名空间，它保留了全收的方便，同时把归属问题解决掉。

第三种是「捕获式收信」，把测试自己发出的信留在本机，根本不走网络。它适合持续集成里的自动化验证，因为不依赖任何外部服务，速度与稳定性都更好；缺点是不会经过真实投递链路，所以上线前仍然需要一小批真实收信地址做补充验证。第四种是「内部邮件测试域」，由团队自己维护，接收范围明确，代价是要有人负责运营。

这几种做法可以叠加：日常自动化用捕获式，预发用带前缀的共享信箱，上线前的验收再补一次真实地址。关键在于每一种都要写清楚它接哪些信、谁负责清理，别让同一个信箱同时承担两种角色。

配置要在评审里看得见：收信范围、清理周期、上限与告警都写在同一个地方，而不是散在几个环境变量里。日志里只记录收到哪个前缀、来自哪类来源，不要把完整收件地址和信件正文写进去，避免预发环境的日志变成第二份数据副本。收件量、拒绝量各留一个可观察的指标，异常时先看指标再看信。

先问自己需要的是「全收」还是「一个能收信的地址」。多数测试只需要后者，那就打开临时邮箱为每个用例生成一个；只有在确实需要任意前缀都能收信时，再考虑全收，并同时把范围与清理规则定下来。验证流程本身的覆盖点，见邮箱验证测试怎么做。

用于测试的收信地址不能作为真实身份或对外联系方式使用。