每一个发送邮件的应用，都需要用真正能收信的地址来测试。Mock 对象能验证你的代码调用了发送函数；但它无法告诉你验证链接是否有效、模板是否正确渲染、引导邮件序列是否按正确顺序触发。要验证这些，你需要真实投递到真实收件箱——最好是零成本、零配置、用完自动清理的收件箱。这正是一次性邮箱的形态。
开发者为什么会选择一次性收件箱
传统替代方案都有摩擦：
- 带加号标签的个人地址会污染你的真实收件箱，在拒绝加号的应用上会失效，而且不方便与队友共享或粘贴到 bug 报告里。
- 在普通邮件服务商开一批专用测试账户意味着要管理凭据、清理收件箱，自动化测试高频访问时还会触发限流或封锁。
- 完整的邮件测试平台（带 API 的捕获服务器）对成熟的 CI 流水线是正确选择，但它们是基础设施：账户、API 密钥、配置，往往还有账单。
来自 MailDrop 的一次性收件箱处在另一个极端：打开应用，使用一个地址，看着邮件到达，继续干活。没有账户，测试笔记里没有凭据，没有清理工作。对于大量手动或半手动的测试任务来说，零配置这个特性就是全部价值所在。
一次性收件箱能测什么
注册与验证流程
最基本的场景。用一个全新的一次性地址注册，验证完整闭环：邮件到达、及时到达、验证链接可以打开、令牌按预期过期、重新请求验证邮件的行为正常。由于每次测试都可以用全新地址，你演练的是真正的首次用户路径，而不是某个已知地址的路径。
事务性邮件内容
密码重置、收据、通知摘要：在一个中立的网页收件箱里打开它们，检查主题行是否合理、链接是绝对地址而不是 localhost、个性化占位符已被填充而不是原样输出、并且存在纯文本备用版本。
边缘情况与失败路径
- 注册后不点击验证链接，确认系统在超时后如何处理未验证账户。
- 对一个随后不复存在的地址触发密码重置——你的流程能否优雅地失败？
- 在地址有效期内重复使用它，测试重复注册的处理逻辑。
一次性域名策略测试
有点讽刺的是，这是最佳用途之一：如果你的产品打算屏蔽一次性域名，你就需要真实的一次性地址来验证屏蔽列表有效、保持更新，并且返回有用的错误提示而不是静默失败。
行之有效的模式
- 每个测试用例一个地址。 地址免费且即取即用；绝不要在多个场景间共用一个。测试运行之间的状态泄漏是邮件测试不稳定的经典根源。
- 用测试名称命名地址。 一个编码了工单号或场景的可读本地部分，能让后来打开收件箱的人一眼看懂，分诊时自带文档。
- 搭配生成的测试数据。 注册表单还需要姓名和资料；身份生成器可以生成连贯的占位用户，密码生成器则为每个测试账户提供唯一凭据，这样即使预发布数据库泄露，也不会暴露团队复用的密码。
- 把只收不发的限制写进文档。 MailDrop 收件箱只能接收，不能发送。需要用户从邮件客户端回复的流程需要别的工具——把这一点写进测试计划，而不是在冲刺中途才发现。
诚实的局限——标准化之前必须知道
- 收件箱是公开的。 任何知道地址的人都能读取一次性收件箱。绝不要向其发送真实用户数据、生产环境凭据或保密的发布信息。只能用测试数据。（总体取舍见临时邮箱安全吗。）
- 过期既是特性也是约束。 邮件会按计划消失。不要把一次性地址用于团队下个月还要访问的任何账户——预发布环境的管理员账户应该使用真实、受控的地址。
- 不能替代 CI。 对于需要以编程方式断言邮件内容的大批量自动化测试套件，API 驱动的捕获服务或自托管 SMTP 收信端才是正确工具。一次性网页收件箱的闪光点在于手动 QA、探索性测试、演示，以及复现用户报告的问题。
- 第三方服务的条款依然适用。 当针对他人的平台（OAuth 提供商、交易市场）进行测试时，遵守对方关于一次性地址的规则。自己的系统随便测；他人的条款要尊重。
关于对用户的同理心
花一天时间用一次性地址做测试，会学到一个有用的产品课：你的用户也有同样的选择。你的转化漏斗中每一个多余的邮箱要求——看演示前的强制注册、文档前面的邮箱墙——都是注重隐私的用户递给你一个会过期地址的地方，正如网站为什么出售你的邮箱所描述的。如果你收集的地址永远不会被用来提供有价值的东西，不如考虑不收集。有时候，邮件测试最好的洞见是：这封邮件本不该存在。
开始使用
没有什么上手流程可讲。打开 MailDrop，把下一次注册测试指向显示的地址，验证邮件就会在网页收件箱里等着你。测试结束后，清理步骤就是——没有清理步骤。