不要先盲目加长超时：先确认应用有没有触发邮件，再区分发送端接受、受控收件端实收、邮件关联和测试断言超时；根据证据修对应环节，并用有上限的轮询复测自家流程。适用条件是测试自家 Web 或 App 的注册、验证码或验证链接，不是测试第三方平台。
本周建议：先给一次失败补齐可复核证据，再决定修触发、修读取还是调整超时。
负责注册验证流程的开发者，可据此定位应用逻辑与邮件链路的故障边界。
维护 E2E 自动化的 QA 工程师，可区分测试超时、邮件迟到、错读邮件与流程未触发。
遇到 CI 偶发失败的独立开发者，可用受控收件和运行标识复现问题，而不是依赖固定等待。
E2E 邮件验证测试超时，先判断失败证据停在哪里
断言超时只说明预期条件没有在限定范围内满足，不能单独证明邮件发送失败或没有到达。要判定一次 E2E 邮件验证是否通过，至少要能证明：邮件属于本次运行、测试代码读到了正确内容、验证动作按预期完成，而且自家应用中的账号状态符合预期。只检查“收件箱里有一封信”还不够；只看到页面提示“已发送”也不够。
把链路拆成可分别观察的阶段：
- 应用触发：注册请求到达了吗？业务条件是否满足？邮件逻辑或队列任务有没有执行？
- 发送端处理：应用有没有调用发送服务？服务返回的是拒绝、排队，还是接受？
- 测试收件端实收：目标地址和环境是否一致？受控收件箱里是否实际出现邮件？
- 测试读取与业务验证：读取器是否找到了本次邮件？验证码或链接是否被正确提交？账号状态是否变化？
发送端的成功响应不能代替收件证明。SMTP 规范中，接收服务器接受邮件，表示其承担后续投递或中继责任；这仍不等于邮件已进入测试代码能够读取的收件箱。RFC 5321 对 SMTP 接收责任的说明
没有生成预期邮件时，先查应用而不是收件箱
先看注册请求和应用日志。请求若没到应用，问题在页面、网络、表单校验或测试环境；请求到达但业务条件未满足，邮件逻辑可能不会执行；业务条件通过却没有邮件任务，则应沿着调用路径检查邮件逻辑、队列配置或测试替身是否启用。
此时反复刷新收件箱、换地址或延长轮询都不会补出一个尚未生成的邮件任务。检查时可以对照请求记录、账号状态、队列任务和发送调用日志，确保它们来自同一轮运行。若测试环境接入了拦截式邮件配置，也要确认当前测试实际使用的发送路径，而不是误把沙箱行为当作公网收信。
正在搭建注册流程测试时，可参考自家产品注册验证码邮件测试的实操路径，把请求、邮件和验证结果分开记录；这比只断言页面按钮已点击，更容易发现业务分支没有触发的问题。
发送端有结果、收件箱却空时，分别核对两边证据
“接口返回成功”可能代表请求被应用接受，也可能代表发送服务接受了任务；它不能自动证明目标收件箱已收到邮件。先保存发送端的任务状态、服务返回标识和目标地址，再到受控收件端查看是否出现相应邮件。发送日志显示拒绝、排队或退信时，处理方式各不相同，不应统一归结为等待时间不够。
再核对以下项目：
- 注册表单提交的地址，是否与邮件任务中的收件地址一致；
- 当前测试运行连接的，是预期的开发、预发布或测试环境；
- 应用是否把邮件发往测试替身，而读取端却在另一个真实收件箱查询；
- 受控收件端是否能查看该地址的来信，是否存在筛选、访问权限或读取接口问题。
需要确认的是“这封邮件是否真的进入受控收件端”，可先了解临时收件箱与邮件沙箱的验证边界：沙箱能帮助检查内容和发送分支，但不能代表邮件已走到可读取的真实收件端。
收件箱已有邮件但测试读不到，先查关联和检索条件
收件端看得到邮件，自动化仍失败，问题可能在读取范围或查询条件，而不是投递。常见原因包括：检索只查了某个文件夹或未读邮件；条件过度依赖主题；邮件尚未被读取接口索引；收件地址不一致；测试把旧邮件或另一轮运行的邮件误认成当前结果。
Playwright 邮件测试中，处理异步结果时应让断言反复检查真实条件，而不是先取一次结果再立即判断。官方文档说明，Playwright 的异步断言会重试直到条件成立或达到断言超时；更复杂的读取条件可用 expect.poll。下面是示意写法，readInbox 需要替换成团队自己的受控收件读取函数：
await expect.poll(
async () => readInbox({ address, runId }),
{ timeout: MAIL_WAIT_BUDGET }
).toMatchObject({ runId });
这里的重点不是照抄一个等待数字，而是让读取器返回能关联本次运行的邮件，并让轮询有明确上限。Playwright 的断言与 expect.poll 文档
若无法把邮件关联到某次注册，优先增加不含敏感信息的运行标识，或改进测试地址与账号的映射。不要只按“最新一封”取信：并发运行、旧验证码和重发邮件都可能让“最新”指向错误对象。CI 记录应保留运行标识、脱敏后的收件地址和验证结果，不要输出有效验证码、完整验证链接或收件访问凭证。
断言、用例与 CI 超时必须分开诊断
Playwright Test 的不同超时限制相互独立。当前官方文档列出的默认值中，单个测试用例超时为 30 秒，异步 expect 断言超时为 5 秒；测试用例还可能被整次测试运行的全局超时提前终止。以上是框架默认值，不是邮件到达时限，也不应直接当作推荐等待预算。Playwright 超时说明与测试配置 API分别描述了这些配置范围。
排查时先看失败报告指出的是断言超时、用例超时还是整次 CI 运行超时。比如，用例仍在运行，但邮件断言先结束，说明应检查断言预算或轮询逻辑；如果整条用例被终止，则邮件轮询可能还没用完自己的时间。记录明确的上限，才能避免内部轮询无限等待、或让 CI 先结束却误以为收件端失败。
固定休眠只能延后下一步，并不能验证邮件是否到达。Playwright 官方 API 将 waitForTimeout 标为不建议在生产测试中使用，并提醒基于计时器的测试容易不稳定；调试时可临时等待观察，正式用例应轮询邮件状态或等待明确事件。Playwright 关于 waitForTimeout 的说明
用可勾选清单决定修复、重跑还是扩大验收
- [ ] 为本次注册创建可追踪的运行标识，并记录脱敏后的测试地址、环境和触发结果。
- [ ] 查看应用日志，确认注册请求到达、业务条件成立、邮件逻辑或队列任务已执行。
- [ ] 对照发送服务结果，分清请求失败、队列等待、服务接受或拒绝；不要把“成功”标签写成收件证明。
- [ ] 到受控收件端确认是否实收，并核对地址、主题、接收时间和本次运行标识。
- [ ] 若已实收但测试失败，检查读取范围、过滤条件、旧邮件匹配和共享收件箱串读。
- [ ] 对照 Playwright 断言、用例和 CI 全局超时，找出最先结束的那一层，再决定是否调整预算。
- [ ] 修好触发、关联或轮询后，先重跑对应的自家产品场景；需要证明邮件实际进入收件端时，再做受控收件验收。
| 观察到的现象 | 当前证据能说明什么 | 下一步 |
|---|---|---|
| 应用没有邮件任务记录 | 还不能证明邮件已触发 | 查注册请求、业务条件、邮件逻辑和测试环境 |
| 发送服务有接受结果，收件端为空 | 发送端有处理结果，测试实收尚未证实 | 核对目标地址、环境、退信和受控收件观察 |
| 收件端有邮件，自动化断言失败 | 邮件已被收件端观察到，读取或匹配仍可能有误 | 核对查询条件、运行标识和断言超时 |
| 验证码已读到，账号仍未验证 | 邮件内容可读，但业务验证尚未闭环 | 提交对应验证码或链接，并检查自家应用账号状态 |
对照验证码收到后如何核实账号注册状态，可以避免把“邮件已收到”误判成“验证已完成”。一轮测试的结果只说明该次环境、地址和流程的观察，不应扩大成生产邮件必然送达的保证。
常见问题
E2E 测试等不到注册验证邮件，排查从哪里开始？
先确认注册请求是否到达自家应用，以及应用日志里有没有创建邮件任务；若没有，先查业务条件、表单请求和测试环境配置。若应用已记录发送结果，再核对收件地址、运行环境和受控收件端。单看测试超时，无法判断邮件没发出还是测试没读到。
发送接口返回成功，为什么受控测试收件箱还是空的？
接口成功可能只说明应用已提交任务，或发送服务已接受邮件，不等于测试收件端已经收到并能读取。对照任务状态、服务返回标识、收件目标和退信记录，再直接观察受控收件箱。没有收件观察时，应把结论记为“发送端有结果、收件未证实”，不要标成送达成功。
邮件测试超时，是等待太短还是应用没有触发发送？
用应用日志分流：没有请求或邮件任务，先查注册条件、代码路径和环境；有任务但没有服务接受记录，查队列或发送调用；发送端有结果但收件箱空，再查目标地址和投递状态。只有在确认流程已触发、收件端可用且轮询覆盖了合理观察窗口后，才调整等待预算。
自动化测试怎样确认邮件属于本次注册，而不是旧邮件？
为每次运行生成可追踪的标识，并把它关联到测试账号、收件地址或应用日志；读取时同时检查收件人、主题、时间和正文中可安全使用的标记。不要只按“最新一封”取信，也不要记录有效验证码或完整验证链接。共享收件箱里若出现错配，应先修关联，不要只延长轮询。
需要确认真实收件时，再使用受控收件
如果目标只是证明自家注册测试邮件确实进入一个可读取的收件端，可把 HideRelay 作为受控收件方式之一：页面说明无需注册即可开始收信，使用独立临时地址可避免在测试表单里填入主邮箱，也能减少测试邮件混进工作邮箱。地址有效期和邮件保留条件应以页面当前说明为准；它只适合短期测试，不适合银行、支付、政务等重要账户，也不适合需要长期找回或持续收信的账号。可从 HideRelay 测试收件箱查看当前收件方式，再按自家系统日志与收件观察分别记录验收结果。