上线前大家都会检查功能，但邮件往往只被顺手点一次：收到了就算过。事务邮件测试清单的意义，是把「有没有发出」升级成「发得对不对、会不会重复发、地址错了怎么办」。下面按触发点、内容、重复触发三条线展开，每条都给出可以照着核对的点。
先列清哪些邮件算事务邮件
先分清楚类别，后面的规则才不会串。事务邮件是用户某个操作触发的、与账号或订单直接相关的那一类，比如注册确认、重置密码、订单状态变更、安全提醒。营销邮件则是推广性质的，两者的发送规则与用户预期都不一样。
分不清的典型是「产品更新通知」：它由事件触发，但目的偏向推广。把它归错类别，会导致退订策略与发送时机都错位。分类完成后要落到一张表上，写明每封邮件的触发动作、收件人、期望到达时间与失败时的表现——空着的格子往往就是漏测的格子。
| 触发动作 | 对应邮件 | 核对重点 |
|---|---|---|
| 注册提交 | 确认地址 | 链接可用、失效后行为明确 |
| 请求重置密码 | 重置链接 | 只发给请求者、旧链接失效 |
| 订单状态变化 | 状态通知 | 状态与内容一致、不重不漏 |
| 检测到异常登录 | 安全提醒 | 文案不泄露多余信息 |
触发点检查：每封邮件都有出处吗?
核心问题是反向核对：清单里的每封邮件，都能指出是哪个动作触发的；反过来，每个会发信的动作，都在清单里有记录。两边都对齐，才算覆盖完整。
具体核对这些点：同一动作是否会发出多于一封邮件；不该发信的动作是否悄悄发了信；内部动作（比如后台改状态）是否会触发面向用户的通知；发信失败时用户看到什么。最后一条最容易被忽略——信没发出去，但页面提示「已发送」，用户会一直等。
另有一条边界要守：事务邮件里不要放超出用途的信息。安全提醒不该把完整设备信息、地址信息写进去，这些内容一旦寄错人，损失比没发信更大。
内容检查：变量、链接与退订
内容检查的重点不是文案好不好看，而是变量有没有兜底。收件人姓名、订单号这类变量来自数据，数据缺字段时必须有一个默认显示，而不是显示成占位符或空白。上线前用手工构造的缺字段数据跑一遍，比读一遍模板有用得多。
链接要逐个点开：确认指向正确环境、带上必要的标识、失效之后有明确提示。退回与不投递的地址如何被标记，也要有结论。
退订方面，事务邮件与营销邮件的规则不同，别用同一套策略。营销邮件通常需要提供一键退订，事务邮件则按业务必要性处理；把两者混在一起，容易出现「用户退订后收不到安全提醒」这类问题。
重复触发会重复发送吗?
会，而且这是事务邮件最典型的事故形态。用户连点两次按钮、系统重试、队列重复消费，都会造成同一封邮件发出多次。用户收到两封「重置密码」，第一反应是账号被人动过。
核对办法是主动制造重复：连续触发同一动作、在发送失败后观察重试、让同一事件被消费两次，然后看收件箱里有几封。断言要点是「同一事件一段窗口内只有一封」，而不是「一封都没有」。
重复投递与延迟本来就是邮件链路的正常现象，所以判断标准要写成「尽量不重复」加上「重复了也不产生危害」，而不是假设它一定不会发生。
在本站的临时邮箱里当收件人
核对这些点需要一批随时可用的收件地址。打开临时邮箱，为每个触发场景生成一个地址，收件箱里能直接看到发件人、主题与正文，变量有没有渲染成功一眼就能看出来；做重复触发测试时，同一个地址收几封也就数得清。
它适合放在上线前的自检与排查阶段：不需要注册、不需要配置，地址用完即弃，不会把你自己的工作邮箱淹掉。地址与信件的生命周期，见临时邮箱原理。
给开发者：幂等、重投与日志边界
幂等要落在发送这一层：同一个事件重复处理时，只允许产生一封邮件。实现方式通常是给事件或邮件一个可去重的标识，发送前先判断是否已经发过。别只在界面层禁用按钮，重试与队列不受界面约束。
投递失败要有明确的重投策略与上限，并在超过上限后把结果记录下来，而不是静默丢弃。模板变量要有默认值，缺失时不渲染成半句话。日志里不要写完整的地址与验证码，只留能定位问题的最小信息；排查需要时用内部标识去关联。
测试覆盖上，把「变量缺失」「地址被拒」「重复触发」这三条各写一个用例，通常就能挡住大部分事故。验证码场景的取信与解析见端到端测试里的验证码；完整验证流程的检查点见邮箱验证测试，第三方注册场景的实测记录见用临时邮箱测试注册流程。
手工核对与自动化各管什么
清单里的事项不该都靠人工点一遍，也不该都写成自动化。适合自动化的是形状固定的判断：同一事件是否只发出一封、变量是否都渲染出了内容、链接是否指向正确的环境。这几项每次改动都可以重跑，成本很低，而且能挡住大部分回归。
适合人工核对的是判断类的事项：文案在缺字段的情况下读起来是否通顺、安全提醒有没有写进多余信息、状态通知的内容与用户看到的页面是否一致。这类问题自动化只能发现「字段为空」，判断不了「读起来是否合适」。
分工之后，清单本身也要维护。新加的邮件要补进表里，下线的邮件要从表里删掉，触发动作改名时对应的行也要跟着改。清单一旦和实现脱节，就会从保障变成摆设——大家照着核对一遍，却漏掉了真正新加的那封。
建议把清单放在需求评审时过一遍：这个功能会发哪些信、什么时候发、发不出去怎么办。在动手之前回答完这三个问题，比上线前一晚补测试便宜得多。
下一步
把清单落成一张表，逐条填上触发动作、邮件与核对重点，空着的格子先补测试用例。核对过程中要真实收信时，用临时邮箱生成地址即可。
清单中使用的收信地址仅用于测试，不可代表真实身份或作为对外联系方式。