在持续集成里让测试去连真实的邮件服务，是很多偶发失败的源头：网络抖动、对方限流、队列延迟，任何一条都会让用例红一次，而你明明没有改坏任何东西。测试环境捕获邮件的做法，是把发信指向本机的一个收信端口，信落在文件或内存里，测试直接去读它。稳定、快、可离线，也不会把测试数据发到外面去。
把发信指向本机意味着什么
被测系统发信时通常只认一项配置：投递服务的地址与端口。把这一项改成指向本机的收信服务，发出去的信就不再离开这台机器。收信端的行为可以很简单——收下、存起来、留给测试读取。
对测试来说，好处是链路被截短了：没有外网、没有对方队列、没有垃圾邮件判定，剩下的只有你自己的逻辑。这样失败时你可以确信问题出在被测代码里，而不是出在别人家的服务器上。
这也让本地开发变得容易：不需要申请任何凭据，不需要连内部网络，克隆下来就能跑。
为什么不该让测试去连真实邮件服务
- 不稳定：网络与对方限流都不受你控制，用例会随机失败。
- 慢：一次投递要等多久无法预期，整条流水线被拖长。
- 会污染：测试地址可能真的收到营销邮件或退信，混进断言里。
- 有泄露风险：测试信件里可能带着内部信息，不该寄到第三方。
还有一条更现实的理由：在自动化里连真实邮箱，意味着你需要维护一套凭据与配额。凭据会过期，配额会用完，而这两件事通常在最不方便的时候发生。
捕获下来的邮件能断言什么?
能断言的东西比很多人以为的多。除了「有没有发出」和「发给谁」，还能检查主题、正文里的变量是否渲染成功、链接指向哪里，以及同一个事件是不是只发出一封。
这里要提醒一点：断言应该落在内容与结构上，而不是落在时间上。等待固定秒数再检查收件箱，会让用例在慢机器上失败、在快机器上掩盖问题；正确做法是轮询到出现为止，并设一个上限。
如果被测系统支持多语言模板，捕获式测试也很适合检查「换了语言之后标题与正文字段是否都跟着换」，这类回归在真实投递里很难稳定复现。
每个用例一个地址，还是共用一个信箱?
两者都可以，取决于你的收信端能不能分流。共用信箱省事，但要让每封信带上可识别的归属信息，否则解析时只能靠猜；每个用例一个地址更干净，代价是要管理地址的生成与清理。
在自动化里，隔离通常比省事更值钱：一个用例读到另一个用例的信，会产出一个与代码无关的失败，排查成本极高。所以更推荐的做法是每个用例一个地址，并在用例结束时把它丢弃。
在本站的临时邮箱里对照着看
本机捕获解决的是「测试自己发出去的信」，而临时邮箱解决的是「作为收件人收下外面的信」，两者经常一起用。要收一封真实投递过来的信时，打开临时邮箱生成地址即可；想知道临时信箱本身是怎么工作的，可以读临时邮箱原理。
如果你在预发环境里需要任意前缀都能收信，那是另一种取向，代价与范围见全收地址的做法。
给开发者：并发、超时与失败留证
并发下最容易出问题的是收信端本身：多个用例同时读同一个信箱，谁都可能把别人的信拿走。解决办法是隔离地址或隔离进程，并让读取操作带上明确的筛选条件。
超时不要写成固定等待，而应该是一个带上限的轮询，并且上限要能在流水线配置里调整。失败时保留原始报文，哪怕只保留最近几封；没有原始报文，失败现场只能靠猜。
最后，清理也要写进用例：跑完把地址与收下的信一起丢掉，否则下次运行时旧信会干扰解析。解析逻辑该怎么写更稳，可以参考验证码出现在端到端测试里。
捕获式测试漏掉的那部分，谁来补
本机捕获把外网剪掉了，这也意味着它验证不了真实链路上的问题：域名是否配置正确、发信身份是否被接受、对方会不会把信判成垃圾、投递延迟是否在可接受范围内。这些恰恰是上线后最容易出问题的地方，所以不能只靠捕获式测试。
通常的做法是分两层。日常与每次提交用捕获式，保证逻辑正确、速度快、不会因外部原因随机失败；上线前或定期用一批真实地址做一次投递验证，确认信确实能到、内容与链接都正常。第二层不需要覆盖所有用例，只要覆盖每类邮件各一封即可，成本很低。
还有一类只在真实链路上才会暴露的问题：信里的链接指向了错误的环境。本机捕获时链接往往被替换成测试地址，看起来一切正常；真投递时却把用户引向了预发环境。做真实投递验证时要专门点一次链接，确认落点与预期一致。
分层的意义在于：把「逻辑对不对」与「信能不能到」分开对待，前者靠捕获式高频验证，后者靠真实投递低频确认。两者互相替代不了。
配置也要能被审查：收信端口、收件目录、清理时机写在同一处，避免某个用例偷偷改回真实投递地址。流水线里加一条断言，确认运行期间的收信记录都来自本机，一旦出现对外投递就失败——这比事后再去翻日志可靠得多。
下一步
先确认你的发信配置能不能指向本机；可以的话，把测试改成捕获式，再按上面的检查点逐步收紧断言。需要真实收一次信时，用临时邮箱拿一个地址即可。整套验证流程的覆盖点，见邮箱验证测试怎么做。
测试中产生的地址与信件仅用于验证流程，不能当作真实身份使用。