有价值的邮件测试不应止于“收到了一封邮件”。它应该从干净的收件地址开始，只触发一个已知动作，等待与该动作对应的消息，检查消息上下文，再验证应用最终状态。临时收件箱的优势在于收件人可以按场景丢弃；如果所有测试都共享同一地址，这个优势也会消失。
把流程拆成可诊断的层
| 层 | 要回答的问题 | 典型失败 |
|---|---|---|
| 触发 | 应用是否创建了邮件事件？ | UI成功但没有发送job |
| 投递 | 是否到达正确收件人？ | 地址、队列或路由错误 |
| 消息 | 发件人、主题、内容和action是否正确？ | 旧模板、旧code、错误环境URL |
| 动作 | link/code是否改变正确状态？ | 邮件正确但backend失败 |
| 清理 | 下一次run是否独立？ | 共享状态残留 |
可重复的手工流程
- 1
创建新的收件人
新注册、唯一identity或recency测试尤其需要。
- 2
只触发一个动作
观察第一封邮件前不要反复点击。
- 3
检查完整上下文
核对收件人、发件人、主题、语言、URL/code和时间。
- 4
完成用户动作
使用link/code并验证应用最终状态。
浏览器隔离不等于邮箱隔离
Playwright和Cypress会隔离浏览器状态，但外部邮箱仍然可能是共享状态。两个并行测试使用同一收件人时仍会发生碰撞。
把收件地址当成fixture的一部分，就像user和backend data一样。
手工 QA 与 CI 自动化不是同一边界
网页临时收件箱适合探索和人工诊断。如果CI必须程序化创建地址和读取邮件，应使用真正支持这些能力的测试基础设施，不要假设MailOnce存在尚未实现的公开API。
临时邮箱真正提升测试质量的方式是减少共享状态。一个场景拥有自己的收件人、trigger和最终结果，失败就更容易解释。
需要一个干净的收件地址做手工邮件 QA？
使用 MailOnce 检查真实的注册、OTP、魔法链接、密码重置和通知邮件，无需把个人邮箱放进测试数据。
创建临时邮箱来源与延伸阅读
用于支撑测试建议的安全资料和测试运行器一手文档。
继续测试
继续查看同一邮件测试问题空间中的下一个边界。