地址是这一个，而且还有效吗？
回到首页核对完整地址与剩余时间。旧截图、上一轮的剪贴板和浏览器自动填充，都可能把邮件送到另一个 case。
- 比较表单实际提交的地址与当前收件箱地址，逐字符检查。
- 核对请求发生时地址是否有效，之后是否换过地址。
- 留意首尾空格、漏字，以及测试环境是否改写了收件人。
先判断，再继续这一轮
收不到验证码，先查三处证据
不要只看“发送成功”的页面提示。每跨过一个环节，都找一条能与当前地址和触发时间对应的记录。
业务端真的提交了发信任务吗？
“注册接口成功”与“验证码邮件已发出”不是同一件事。有些系统先返回页面结果，再异步安排邮件任务。
- 记录触发时间、HTTP 响应和请求标识，不只保留按钮截图。
- 查业务日志中是否创建发信任务，收件人是否正确。
- 检查重发冷却、频率限制、测试开关与邮箱域名限制。
投递日志停在哪一个事件？
服务商接单不代表最终收件箱已经展示邮件。用消息标识找完整事件链，比重复触发一封新邮件更有帮助。
- 查排队、延迟、接受或退信事件，并保留事件时间。
- 若有 SMTP 响应，核对接收域、响应码和退信原因。
- 区分服务商接受请求与收件服务器接受邮件两种“接受”。
把证据放在同一张桌面上
这一轮，下一步该查哪里？
按已知事实选择。没有日志就选“不确定”，它是一条有效信息，不是发信故障的证据。
本地检查建议
这个面板不会连接你的发件系统，也不会自动检查邮箱。选择只在当前页面处理，不上传、不保存。
先选已知事实，再生成建议
即使三项都不确定，也可以开始。面板会列出优先补齐的证据，不会把“没有记录”判断为“发送失败”。
等待，不只有一种状态
“已发送”这三个字，还不够具体
收件箱能告诉你邮件有没有出现，却不能替发件系统解释任务为什么没执行、为什么还在队列里。
尚未发出
业务端没有创建发信任务，或被冷却、频控、环境配置拦住。此时反复刷新收件箱不会推动任务执行。
- 收件箱可见
- 没有对应的新邮件，但无法从中判断未发出的原因。
- 需要核对
- 业务请求响应、任务创建日志、收件人和限流记录。
服务商排队
发信服务已有任务，但暂时还没完成投递。短时延迟、重试策略与服务商自身队列都可能影响这一阶段。
- 收件箱可见
- 邮件暂未出现；仅凭等待时长不能断言它已经丢失。
- 需要核对
- 队列时间、重试事件、最近响应，以及服务商的重试安排。
已接受
先看是谁接受：API 接受发信请求，只说明服务商接单；接收服务器接受邮件，才是更后面的投递证据。
- 收件箱可见
- 出现邮件可确认本站已展示；尚未出现时不能仅靠标签定位问题。
- 需要核对
- 事件定义、最终收件地址、SMTP 响应和接受时间。
退信或拒收
退信是一条可追查的结果，但原因未必是代码错误。地址、域名策略、发件信誉和内容策略都可能参与判断。
- 收件箱可见
- 被拒收的邮件通常不会显示在目标收件箱里。
- 需要核对
- 完整状态码、原因说明、目标域名，以及是否仍会重试。
如果你没有发信日志访问权限，请把触发时间与请求标识交给系统维护者。不要为了补证据，把生产 API 密钥或完整验证码发到支持邮件里。
-
复制并核对现有地址
从首页复制，不从旧截图重打。把业务实际提交的收件人与当前地址比较，并确认剩余有效期足够完成这一轮。
-
先看重发冷却，再触发一次
遵守业务端显示的冷却时间与频率限制。部分系统只认可最后一次生成的验证码，连续重发可能让先到的那封立即失效。
-
记下时间，追同一条请求
记录时区、请求标识与投递消息标识。需要对照时，可以让另一套你有权限使用的发信系统向同一地址发送一封无敏感内容的测试信；对照信到达不能证明原链路必然正常。
-
确有必要，再换地址复测
先保存不含敏感信息的记录，再点击首页的“换一个地址”。换址会销毁旧邮箱；旧地址不再作为当前测试入口，旧请求也不会自动改投新地址，必须重新提交。
让这一轮 case 可以复盘
一张够用的到达排查记录
能把发件端与收件端对上，就不必收集更多。只记录排查所需字段，团队分享时遮去不必要的个人信息。
| 字段 | 怎么记 | 能帮助确认什么 |
|---|---|---|
| 测试环境与用例 | 预发 / 测试；注册、找回密码或 OTP 校验；必要时附构建版本。 | 是否使用了错误环境、测试开关或不同邮件配置。 |
| 实际收件地址与有效性 | 内部核对时记录提交的完整临时地址、是否与当前地址一致、请求时是否有效。 | 这一封邮件究竟应落进哪一个 case。 |
| 触发时间与时区 | 例如 2026-11-03 14:05:20 +08:00；如有重发，分别另记一行。 | 业务日志、服务商事件与收件结果是否属于同一次触发。 |
| 请求与消息标识 | 业务 request ID、任务 ID、服务商 message ID；不存在就写“未取得”。 | 从页面请求一路追到异步任务和投递事件。 |
| 请求响应与投递结果 | 响应状态、排队 / 接受 / 退信事件、事件时间及必要的状态码。 | 问题停在哪一段；哪些结论仍缺证据。 |
| 收件观察与下一步 | 检查时间、是否看到邮件、是否已换址，以及下一步由谁核对什么。 | 避免重复触发，并保留后续交接所需的信息。 |
验证码邮件多久能到？
新邮件通常几秒内出现，但没有对所有发件系统都成立的固定到达秒数。首页约每 7 秒检查一次收件箱，这只是页面检查间隔；业务队列、服务商重试和接收处理的时间另计。久等时应查看投递日志，而不是把刷新间隔当作投递承诺。
应该连续点“重新发送”吗？
不建议。先等业务端冷却结束，再只触发一次并记录时间。连续重发可能触发限流，也可能让旧验证码失效；稍后多封一起到达时，更难确定当前有效的是哪一封。
地址到期后，还能接收之前发出的邮件吗？
不能把过期地址继续当作有效收件入口。Tempcase 临时地址默认 3 小时有效，有效期内每次续期追加 3 小时，单个地址累计最长 24 小时；到期后地址与邮件会被清除且无法恢复。服务商仍在重试的旧任务不会因此自动改投新地址。
收不到，能证明我的代码有错吗？
不能。地址错误、未创建任务、排队、域名限制和拒收都可能表现为“收件箱没信”。只有把当前地址、请求标识与投递事件对应起来，才能逐步缩小范围；没有日志时，应保留未知，而不是直接判为代码故障。
日志显示“已投递”，收件箱却没出现怎么办？
先核对该服务商对“已投递”的定义、最终收件人和事件时间，再确认当前地址未过期、未换址，并手动刷新一次。仍有差异时，可将发生时间、临时地址及脱敏后的消息标识发给 support@tempcase.com，请勿附验证码或生产凭证。
每个网站都接受一次性邮箱吗？
不是。部分业务会限制临时邮箱域名，可能直接拒绝请求，也可能只显示笼统提示。请核对该业务的规则与响应，不要用反复换址绕过限制。自己的预发测试应通过受控配置处理；需要长期接收找回邮件的账号，可考虑长期转发别名。