邮件是导致自动化测试运行不稳定的缓慢、繁琐的依赖项。注册测试可能在本地通过，但在CI中失败，原因是收件箱已包含旧的验证链接、邮件延迟到达或解析邮件正文不稳定。解决方案很简单：为每次测试运行生成一个新的临时邮箱收件箱，然后对接收到的消息进行结构化断言。
本指南展示了一种实用、可重复的方法，用于通过编程方式创建临时收件箱、可靠地收集邮件，并在QA自动化和LLM驱动的代理中使用它们。
测试运行中”临时邮箱收件箱”的含义
对于测试而言，临时收件箱不仅仅是一个随机的邮箱地址。它是一个你可以：
- 按需创建（每次运行、每个规格或每个用户）
- 自动读取（无需人工打开UI）
- 关联到特定测试上下文（运行ID、场景ID）
- 在运行结束后删除或忽略
这很重要，因为许多”临时邮箱”网站是为人类而非自动化构建的。它们通常有速率限制、无API、交付不可靠，且无法安全地集成到CI中。
💡 不再处理不稳定的邮件测试
Mailhook消除了不可靠临时邮箱提供商的麻烦。通过编程方式创建临时收件箱，以结构化JSON接收邮件，构建坚如磐石的测试自动化。开始可靠测试 → 或 查看API文档 →
Mailhook专为自动化和代理而构建：你通过API创建临时收件箱，然后通过轮询或实时webhook以结构化JSON格式接收入站邮件。
需要新收件箱的常见测试运行场景
在产品发送邮件并期望用户采取行动的任何地方，临时收件箱都会带来收益：
- 注册验证（OTP代码、验证链接）
- 密码重置
- 魔术链接（无密码登录）
- 邀请（工作区邀请、团队成员入职）
- 邮箱更改确认
- 入站邮件解析（支持回复、入站路由、回复处理）
- 代理工作流，其中LLM必须”接收邮件”并提取令牌
如果你构建涉及推广或潜在客户处理的自动化，你还希望在暂存环境中使用临时收件箱来测试入站流程，而不污染真实邮箱。例如，构建Instagram潜在客户管道（如Orsay）的团队通常需要在环境间端到端验证跟进和响应循环。
临时收件箱API的选择标准（QA + 代理版本）
并非所有临时邮箱提供商都对自动化友好。以下是实用检查清单及其如何映射到Mailhook的功能。
| 测试运行要求 | 在CI和代理中的重要性 | 在Mailhook中使用什么 |
|---|---|---|
| 编程式收件箱创建 | 你需要每次运行一个收件箱，而不是共享邮箱 | 通过API创建临时收件箱 |
| 结构化消息 | 测试应对字段进行断言，而不是正则表达式HTML | 以JSON格式接收邮件 |
| 实时交付信号 | 避免长时间休眠和不稳定的轮询循环 | Webhook通知 |
| 轮询后备 | 某些CI设置无法接受入站webhook | 邮件轮询API |
| 安全控制 | 在自动化中不信任未签名的回调 | 签名载荷 |
| 域选项 | 共享域快速，自定义域提供控制 | 即时共享域 + 自定义域支持 |
| 批处理友好处理 | 许多测试生成许多邮件 | 批量邮件处理 |
“每次测试运行一个收件箱”模式
最简单可靠的模式是：
- 在运行开始时生成新收件箱
- 在被测应用中使用该地址（注册、重置、邀请）
- 等待邮件（webhook优先，轮询作为后备）
- 对JSON进行断言（主题、收件人、链接、代码）
- 结束运行并丢弃收件箱
关键思想：将收件箱视为测试装置。你的应用绝不应向累积历史的共享地址发送测试邮件。
分步指南：生成临时收件箱并对邮件进行断言
由于端点形状可能随时间变化，最稳健的实现方式是：
- 使用Mailhook API创建收件箱并获取邮箱地址
- 使用webhook交付或轮询获取接收到的消息
- 保持测试断言专注于稳定字段（收件人、主题、提取的URL/令牌）
有关最新接口详细信息，请保持官方参考手册：Mailhook llms.txt。
1) 创建收件箱（测试开始时）
作为测试设置的一部分创建收件箱并存储：
- 生成的邮箱地址（输入到你的UI/API中）
- 收件箱标识符（稍后获取消息）
实现提示：使用确定性运行键命名或标记收件箱（例如 run_2026_01_17_build_1842）。即使你不依赖服务器端标签，在测试日志中保留此值也使调试变得更加容易。
2) 从你的应用触发邮件
运行你想要测试的操作：
- 使用临时邮箱调用你的注册端点
- 或在Playwright/Cypress中完成UI注册流程
此时，你的应用应该向新地址发送邮件。
3) 接收邮件：webhook优先或轮询
Webhook方法（推荐，速度快且可靠）
- 你的测试工具公开回调端点（或小型本地服务器）
- Mailhook将入站邮件事件发布到你的webhook
- 事件到达后立即解除测试阻塞
为了安全起见，在接受事件之前验证签名载荷（Mailhook支持签名载荷）。
轮询方法（当webhook不便时最佳）
- 触发邮件后，轮询收件箱获取消息
- 收到预期消息或达到超时时停止
在CI中，轮询通常更容易连接，但webhook通常减少总运行时间和不稳定性。
4) 对JSON字段进行断言，而非邮件HTML
确切的JSON形状取决于提供商，但结构化邮件载荷通常包括字段如：
- 发件人和收件人地址
- 主题
- 文本正文和/或HTML正文
- 头部
- 附件（如果存在）
测试提示：优选断言如：
- “收件人等于生成的地址”
- “主题包含’验证您的邮箱’”
- “正文包含路径为
/verify的URL”
然后以有针对性的方式解析验证链接或OTP。避免整个HTML的脆弱快照。
使邮件测试更不易出错
大多数失败来自时间和歧义性。这些实践可以加固你的套件。
使用关联，而非猜测
如果你的应用可能发送多封邮件，在请求中包含关联提示，以便你可以快速识别正确的消息。示例：
- 嵌入在注册名称中的唯一运行ID（如果你的模板包含它）
- 测试环境中的独特主题前缀
- 每个场景的独特邮箱地址（最佳选项）
最干净的方法仍然是：每个场景一个收件箱。
用显式等待替换休眠
而不是 sleep(10)，做：
- Webhook：在promise/事件上等待最多N秒
- 轮询：使用短间隔和总超时进行轮询
在CI中的实用起点是30到60秒最大等待，1到2秒轮询间隔。根据你的邮件提供商和环境进行调整。
断言证明正确性的最小值
邮件模板经常更改。你的测试应验证行为，而不是文案。
良好的断言：
- 验证链接存在且有效
- 重置令牌匹配预期格式
- 收件人地址正确
有风险的断言：
- 精确的HTML标记
- 完整段落文本
测试的共享域与自定义域
Mailhook支持即时共享域和自定义域支持。你应该使用哪个？
共享域理想情况是：
- 你想要最快的设置
- 你在运行内部QA和CI，域品牌无关紧要
- 你不需要域级可交付性调整
自定义域理想情况是：
- 你想要现实的暂存环境（例如，
test.yourcompany.com） - 你需要更多控制你生态系统中邮件的发送/接收方式
- 你想要密切镜像生产假设
实际上，许多团队从共享域开始以获得速度，然后在测试稳定后添加自定义域。
在LLM代理中使用临时收件箱
LLM代理经常需要完成涉及邮件的工作流：
- 创建试用账户
- 等待验证
- 提取代码或链接
- 继续工作流
可靠的代理模式是：
- 工具：
create_inbox()返回{ inbox_id, email_address } - 工具：
wait_for_email(inbox_id, filter)返回下一个匹配的邮件JSON - 代理逻辑：提取
verification_link或OTP并继续
当你使用webhook交付时，你还可以在消息到达时立即将它们推送到代理的事件队列中，减少延迟并消除不必要的轮询周期。
💡 构建处理邮件工作流的更智能AI代理
赋予你的LLM代理创建账户、接收验证邮件和自动提取令牌的能力。借助Mailhook的API优先方法，代理获得完美适合自主工作流的结构化JSON响应。探索AI代理用例 → 或 开始构建 →
如果你正在实现代理工具，保持接口小而确定。当工具返回结构化数据时，代理表现更好，这正是以JSON格式接收邮件的要点。
大规模交付CI的团队实施注意事项
一旦你有许多并发测试运行，一些操作实践会有所帮助：
- **并行性：**每个工作器生成一个收件箱以避免冲突。
- **隔离：**绝不跨运行重用收件箱，即使你”清理”它们。
- **可调试性：**为每次运行记录生成的邮箱地址和收件箱ID。
- **安全性：**验证webhook签名，将邮件内容视为不受信任的输入。
- **吞吐量：**如果你一次处理许多邮件，优选批处理友好的获取和解析以减少开销。
开始使用Mailhook
如果你的测试或代理依赖邮件，临时收件箱是你可以为可靠性做出的最高ROI变更之一。Mailhook正是为此而设计：通过API进行可编程收件箱创建，以结构化JSON交付入站邮件，实时webhook，轮询后备，签名载荷，以及对共享和自定义域的支持。
使用这里的权威功能和集成参考：Mailhook llms.txt。
然后在Mailhook探索平台，开始为你的下一次测试运行生成临时邮箱收件箱。
