测试用虚拟邮箱：注册表单可以放心用的地址
如果你在做网站或测网站，你会不停地往表单里填邮箱地址。唯一绝不能发生的， 是一封测试邮件落进某个陌生人真实的信箱里。这一页告诉你每种测试该用哪种虚拟邮箱地址—— 以及什么时候邮件必须真的送到。
先决定邮件要不要送到
这一个问题决定一切，值得明明白白地问出来，因为答案是「不要」的时候比人们想的多。
| 你在测什么 | 邮件要送到吗？ | 用什么 |
|---|---|---|
| 地址的校验、存储、显示 | 不要 | 保留域名——见下文 |
| 确认流程，手动测 | 要 | 这里的一个信箱 |
| 确认流程，自动测 | 要，而且代码要能读 | 带 API 的服务 |
| 压力测试或批量测试 | 不要——而且绝不能送到 | 永远用保留域名 |
邮件不能送到时：用保留名称
有些域名就是专门为此而设，保证永远不归任何人所有：example.com 和它的兄弟 example.net、example.org（由 RFC 2606 保留）， 再加上整个 .test 后缀。
这些域名上的地址，是示例数据、初始数据和压力测试的正确答案。你发出去的任何东西都到不了人手里， 因为那里没有人——靠的是国际约定，而不是运气。
⚠️
别自己编看起来像真的域名。
test@mycompanytest.com 常常真的是某人的域名，对它做压力测试和攻击毫无二致。 保留名称不花一分钱，就把这一整类事故都排除了。邮件必须送到时，手动测
在这里拿一个地址，跑一遍流程，看看你的应用实际发出了什么——邮件头、链接， 以及不是你自己的邮件客户端显示时，这封信长什么样。有两件事这样能发现，而本地的邮件捕获工具发现不了：
- 真实的投递。邮件走的是真实的邮件路径，所以配置错误的发件方会在这里出错，而不是在线上环境。
- 陌生人眼中的样子。只在你的会话里有效的链接、永远加载不出来的图片、 指向 localhost 的退订链接——一眼就能看到。
如果你的应用会发送文件，也留意一下附件提示：那正是你的用户会看到的提示。
必须自动化的时候
ℹ️
这里没有公开的 API。信箱要通过页面来读， 没有任何东西提供给脚本去轮询。我们把话说明白，免得有人花一下午去找：需要读邮件的自动化测试， 请用专门为此打造、带账号和密钥的服务。
改去抓取页面，就算能跑通也是笔坏买卖：脆弱、没有文档，而且恰恰是那种迟早会被封掉的流量。
测试被拒的情况
有意思的失败并不是「有效地址能用」。值得覆盖的有：
- 一个落在没有 MX 记录的域名上的地址——地址写得没错，投递却会失败。 你的代码应该能分清这两种情况。 查一查哪个是哪个。
- 一个国际化域名，Unicode 形式和
xn--形式都要测。 大多数校验器拒收其中一种、接受另一种，而且通常是反的—— 转换器。 - 带点号和加号的 Gmail 变体。如果你的去重检查直接比较原始字符串，一个人就能无限注册账号。 先做规范化—— 那个页面做的正是你的检查应该做的事。
- 很长的 @ 前缀。标准允许 64 个字符；很多表单会悄悄截到 20 个， 存下一个哪儿也不通的东西。
该去做的，而不是该去测的
如果你的产品不接受虚拟邮箱地址，就明明白白地拒绝。对一个完全有效的地址提示「邮箱无效」， 是这类问题里最让人困惑的错误：用户检查拼写、重新输入，得到同样的提示。 「我们不接受虚拟邮箱地址」占的地方一样大，却能结束这场困惑。