业务触发时间
用户动作或系统事件发生的时刻。它用于判断产品是否及时创建发送任务。
邮件时间语义
同一封邮件，可能同时有四个时间
触发、排队、接收与显示时间不是一回事。先统一时区与事件定义，再判断验证码是否迟到或已经过期。
10:00:00 触发用户提交登录表单，应用创建发送任务。这是业务动作时间。
10:00:02 入队邮件任务进入发送队列。二者差值反映应用与队列衔接。
10:00:08 接收目标服务器接受邮件。与入队时间的差值更接近传输延迟。
18:00:08 显示浏览器以 UTC+8 展示本地时间；它与 10:00:08 UTC 可能是同一瞬间。
先分清含义
不要拿界面时钟直接减
两台设备显示不同小时数，不一定代表投递延迟。先把每个时间转换到同一时区或同一时间戳。
邮件头日期
通常由发件系统写入，可能受服务器时钟、队列与配置影响，不应单独视为接收证据。
接收时间
收件系统记录的接受时刻，更适合衡量实际到达，但仍需明确采用的时区。
界面显示时间
为了阅读会转成本机格式。截图时应同时记录设备时区，否则跨团队容易误判。
有效期起点
验证码可能从生成、发送或服务端签发时开始计时，必须以产品契约为准。
倒计时剩余
倒计时是派生值。切后台、休眠或设备时钟变化后，应以绝对到期时间重新计算。
延迟诊断
把总延迟拆成三段
只有知道时间花在哪一段，才能决定查应用日志、发送队列还是收件策略。
触发到入队间隔大，优先检查应用请求、模板渲染与任务服务。
入队到发出间隔大，检查限速、并发、重试与供应商状态。
发出到接收间隔大，检查 DNS、信誉、临时拒收和远端策略。
服务器已收到但列表晚出现，检查轮询频率、缓存和客户端网络。
验证码过期怎么测
先确认有效期从哪个服务端事件开始，再分别测试有效期内、边界前后和重复使用。不要用手工改设备时钟代替服务端过期。
- 生成后立即使用应成功
- 到期边界附近反馈要明确
- 新码签发后旧码行为要符合契约
跨时区协作怎么记录
缺陷单同时保留 ISO 原始时间、时区偏移和本地可读时间。截图里出现“上午十点”时，文字说明设备时区。
- 事件 ID 连接不同系统日志
- 使用 UTC 作为团队比对基准
- 本地时间用于还原用户体验
快速校验
看到“迟到”先回答四个问题
下面四问能排除大多数时区误会，并把真正的延迟定位到可调查的系统环节。
时间来自哪里？
是应用日志、邮件头、接收服务器还是浏览器列表？不同来源代表不同事件。
时区是什么？
是否带 Z、明确偏移或地区时区？没有时区的时间只能当作不完整证据。
比较的是同一封吗？
主题里的唯一编号、收件地址和任务 ID 必须一致，避免拿重发邮件交叉比较。