可靠的临时邮箱 API 自动化

不稳定的邮件测试通常很短：创建地址，固定等待五秒，读取第一封邮件，然后希望它正好属于这次运行。

可靠版本也不复杂，只是承认邮件投递是异步的。它会创建唯一地址、记录开始时间、在截止时间内轮询、匹配正确邮件、验证产品结果，并在失败时留下足够上下文。

不要把 API Key 放进 URL

GPTMail 密钥应放在 X-API-Key 请求头中，不要使用 ?api_key= 查询参数。URL 经常会进入浏览器历史、访问日志、监控系统和来源信息。

X-API-Key: YOUR_API_KEY

在 CI 的密钥管理中保存 Key，并在日志中隐藏它。公开每日 Key 适合临时体验；受控的自动化测试更适合使用能够独立查看额度和用量的 Key。

当前接口和响应示例以GPTMail API 文档为准。

每个可以独立执行的测试都应生成新地址。不要让整套测试共享一个收件箱，再从里面猜哪封邮件属于谁。

记录地址、场景 ID、环境和开始时间。这些信息足以排除旧邮件并诊断冲突，又不需要在日志里暴露邮件秘密。

邮件投递时间会变化。固定等待五秒，快的时候浪费时间，慢的时候又会随机失败。

使用有边界的循环：

截止时间 = 当前时间 + 90 秒
等待时间 = 2 秒

在截止时间之前循环：
  获取收件箱列表
  找到发件人、主题和开始时间都匹配的最新邮件
  如果找到：读取邮件并继续产品测试
  等待，并加入少量随机抖动
  等待时间逐步增加，最多 10 秒

截止时间应该是测试契约的一部分。密码重置和批量新闻预览可以有不同上限，但都应明确，避免一个缓慢依赖悄悄拖长整个 CI。

“收件箱里的第一封”不是可靠选择器。至少组合这些条件：

发送方可能生成多个验证码时，选择最新匹配邮件，并在测试结果中保留它的 ID，防止重试误用旧邮件。

收件箱列表只负责便宜地发现候选邮件。找到目标后再获取完整正文，可以减少无用读取，也避免解析无关营销邮件。

最终要验证的是业务结果，而不是正文里恰好出现了六位数字。把验证码提交给产品，或打开预期链接，再确认账号进入了正确状态。

API 返回额度或限速响应时，应停止当前尝试并显示重置时间。激进重试只会把清楚的容量信号变成噪声，还可能拖慢其他测试。

在测试运行器层限制并发，尤其是一次创建大量地址时。小规模工作池比几百个同时轮询的循环更容易定位问题。

先保存证据，再执行清理。成功时可以删除邮件，也可以让短期保留策略自然处理。失败时，把地址和邮件 ID 暂时保存在受保护的 CI 产物中，完成调查后再删除。

不要把验证码、私密链接或完整 HTML 正文输出到公开构建日志。

每次重试都应使用新地址重新开始。不要认为同一账号、同一收件箱再次触发就会回到干净状态。发送方可能废除旧码、限制重复请求或拒绝重复邀请。

网络请求超时时，还要区分“没有收到响应”和“操作没有发生”。破坏性重试之前，先检查外部可观察状态。

一份有用的自动化失败应明确属于哪一阶段：

这样，随机出现的“邮件测试失败”才会变成团队能够负责的具体问题。