开发与 QA 知识中心

面向开发者与 QA 的临时邮箱

用隔离的临时收件箱测试注册、OTP、魔法链接和密码重置流程，不要把共享个人邮箱当成测试基础设施。

邮件测试失败往往不是玄学：旧地址被重复使用、上一条 OTP 被误认为最新代码、链接指向错误环境，或两个测试运行读取了同一个收件箱。本知识集群关注测试设计和用户真正收到的邮件。当 CI 需要程序化断言时，普通网页收件箱并不能替代专门的邮件测试 API。

开发者与 QA 指南

每篇指南聚焦一个具体故障模式，而不是重复同一个通用临时邮箱场景。

8 篇重点指南

测试用户真正收到的流程

先隔离场景，再检查邮件本身、验证码或链接、目标环境，以及让下一次运行回到已知状态的清理过程。

为场景使用新的收件地址，并把触发、投递、内容、环境和最终状态分开验证，让失败能够定位到具体层。

把注册验证当成状态迁移：新地址、当前验证邮件、验证动作，以及最终真正变成verified的账号状态。

围绕请求边界、最新code、resend、过期、replay和最终状态测试OTP，不要把收件箱里任意一个数字当成成功证据。

检查收件人、环境、链接、redirect，以及最后建立的认证session身份；只有一个可点击链接并不能证明登录正确。

从请求、token使用、密码修改、replay一直验证到最终登录，不要只检查邮件模板和投递。

让每个test或worker拥有自己的收件地址，避免并行执行互相读取、失效或清理对方的邮件状态。

Polling和event只决定测试如何发现新邮件，并不能控制sender、queue或SMTP真正什么时候完成投递。

共享mailbox把人员、retry、environment和parallel run绑在同一状态里；让每个scenario的recipient ownership明确。