邮件 HTML 仍是一个约束很多的运行环境：客户端会删除样式、代理图片、改写链接，深色模式还可能重新计算颜色。与此同时，模板已经不再只是静态页面，它通常由组件、国际化文案和动态数据共同生成。因此，可靠回归必须同时检查数据合同、结构呈现、行动入口和真实投递。
本指南适合欢迎信、账单通知、团队邀请、密码重置和产品提醒。验证码邮件还需要额外的核销与重发测试，可配合另一篇 验证码完整用例 使用。
建立可比较的基线，而不是保存一张“完美截图”
截图容易理解，却无法说明邮件使用了什么数据、哪些链接可点击，也无法发现不可见的预览文字。更好的基线包含四件东西：模板版本、输入样本、生成后的 HTML 与纯文本、一次真实投递记录。这样，差异出现时才知道是模板、数据还是链路改变。
样本应覆盖内容形状
为每种模板准备短标题、长标题、空可选字段、超长姓名、多语言和多个列表项。不要只用“张三”和一行商品。真正的布局问题常由长德语式词组、日文无空格文本、金额位数或缺失头像触发，即便当前阶段先写中文，也应给组件预留这些形状。
- 最短与最长主题，观察收件箱列表截断是否仍能辨识。
- 名字、项目名和订单号接近允许上限的组合。
- 零项、一项和多项列表，确认条件区块不会留下空白。
- 空图片、慢图片和异常宽图片，验证容器边界。
先检查内容合同，再讨论像素
渲染之前，扫描生成结果中的模板残留，例如 {{name}}、${url}、空括号或开发域名。主题、预览文字、正文标题和主要按钮应该描述同一个动作；用户不应在主题里看到“账单已生成”，打开后却只看到营销更新。
对所有动态值做转义和格式化。用户输入不能成为 HTML；金额要带正确币种与小数规则；时间要说明时区或使用用户所在时区；编号不应被电子表格式格式化为科学计数。数据缺失时应省略对应句子，不能把 “undefined” 发给用户。
先判语义，再判视觉：如果按钮标签、目标 URL 或有效期错了，即使邮件在所有客户端像素一致，也不能发布。
检查预览文字与隐藏内容
收件箱列表常先展示主题和 preheader。预览文字应补充主题，而不是重复标题或抓到“在浏览器中查看”、CSS 片段和图片替代文字。用于控制预览的隐藏字符不能在某些客户端里形成大段空白。
用风险矩阵选择客户端，不要盲目追求全覆盖
从产品真实使用数据选主要桌面、网页和移动客户端，再补一组已知差异最大的引擎。每次提交跑核心矩阵，候选发布版本再跑扩展矩阵。这样既能控制时间，也不会因为“测试了二十种客户端”而忽略占比最高的三种。
视觉检查应围绕任务完成
- 600–700 像素内容宽度在桌面居中，窄屏不横向滚动。
- 标题、正文与主按钮层级清楚，首屏能理解邮件用途。
- 按钮有足够点击区域；文字变长时换行但不裁切。
- 表格用于邮件布局时有语义兜底，阅读顺序不混乱。
- 深色模式下正文、链接、品牌图与按钮仍有足够对比。
不要把“允许客户端缩放”当成响应式设计。大图、固定宽表格和不可断长串会把整封邮件撑出视口。对订单号或追踪链接使用可断行策略，但验证码和短金额通常应保持完整。
逐一验证链接、参数和过期行为
抓取生成 HTML 中全部链接，区分主动作、次动作、导航、退订和法律链接。每条都应使用 HTTPS 正式或测试域名，不能保留 localhost、内部主机名和模板占位。跟踪参数可以存在，但不能破坏业务参数或把敏感值写进可长期传播的 URL。
人工点击主按钮，确认重定向后落到预期页面并保留必要上下文。登录链接和重置链接要在过期后失败，成功使用后不能再次使用。普通内容链接则不应因为短期签名过早失效。
区分视觉按钮与真实链接
有些客户端会删除复杂 CSS，但真正的 <a> 仍可点击。避免用脚本、表单或仅绑定图片热区实现动作。按钮文字应独立说明去向，不要只写“点击这里”；屏幕阅读器用户需要在脱离上下文时也能理解。
关闭图片，打开纯文本，再读一遍
图片可能被默认阻止，也可能经过代理后延迟。关闭图片时，logo 缺失不应影响识别，主动作不能只存在于海报图里，替代文字要解释内容而不是重复文件名。装饰图使用空替代文本，避免读屏把它当重要内容朗读。
纯文本版本不是把 HTML 标签粗暴剥掉。它需要清楚的段落、完整 URL、相同的动态数据和一致的安全提示。若 HTML 说链接 30 分钟有效，纯文本也必须相同。多栏内容在线性文本中要按合理顺序排列。
测试无障碍和认知负担
检查标题层级、链接文案、色彩对比与可读字号。不要只用颜色表达“成功”或“警告”，也不要把五项同等重要的动作画成五个主按钮。邮件的目标通常只有一个，次要信息应降低视觉权重。
把回归分成三层，才能长期执行
第一层在代码提交时运行：校验模板能编译、变量齐全、链接域名在允许列表、HTML 大小不过限、纯文本存在。第二层在预发布环境真实发信：用 隔离测试收件箱 接收，记录主题、发件人、消息 ID 与到达时间，并打开正文。第三层在候选发布版本进行人工矩阵检查，覆盖核心客户端、窄屏、深色模式、无图和读屏顺序。
失败时保存生成输入与输出，而不是只留截图。发送服务显示 accepted 并不等于收件箱已收到；测试收件箱为空时，要对照应用日志、队列和服务商事件。可以沿 邮件送达诊断 的证据顺序定位。
为变化设置不同门槛
只改拼写不必重跑所有客户端，但改布局组件、内联样式器、链接生成器或国际化框架时，应扩大矩阵。把变更类型写进合并请求模板，让执行者知道需要哪一级证据。定期清理过时基线，保留版本和原因，避免团队对差异视而不见。
最后，用 测试邮件检查清单 把主题、预览、正文、链接、时序和隐私边界串起来。回归流程的价值不是产出更多截图，而是在用户收到错误消息之前，给团队一个明确、可重复的停止发布信号。