Novu 事务性邮件目录：按应用类型规划认证、订单与账单邮件的完整指南

2026-09-05 18:24:46作者：戚魁泉Nursing

本文基于 Novu 仓库中 email-best-practices 技能包内的事务性邮件目录展开，系统讲解"你的应用需要哪些事务性邮件"：先给出 8 类应用的必备/可选邮件组合，再逐类拆解每封邮件的发送时机、内容要素与最佳实践。结合 Novu 的工作流触发 API 与官方使用指南，读者读完可以独立完成从"邮件规划清单"到"多通道发送落地"的完整闭环。

目录的定位：先规划，再发送

在 Novu 仓库的 .agents/skills/email-best-practices/SKILL.md 中，事务性邮件目录被明确定位为新应用的第一步："新应用？先从 Catalog 出发规划你的应用需要哪些邮件（密码重置、验证等），发送第一封邮件之前先配置 DNS 认证（Deliverability）。"

目录适用于以下四个场景（继承自原文档 When to Use This）：

规划你的应用需要哪些事务性邮件
根据你的应用类型选择合适的邮件组合
理解每类邮件应包含的内容
实现事务性邮件功能

按应用类型选择邮件组合

原文档为 8 种典型应用类型给出了"Essential（必备）/ Optional（可选）"邮件组合。以下完整继承其结论，可直接作为新项目的邮件规划清单。

1. 认证类应用（Authentication-Focused）

适用对象：以用户账户与安全为核心（登录系统、身份提供商、账户管理）。

级别	邮件
必备	邮箱验证、密码重置、OTP/2FA 验证码、安全告警（新设备登录、密码修改）、账户更新通知
可选	欢迎邮件（不得含推广内容）、账户删除确认

2. 新闻简报 / 内容平台（Newsletter / Content Platform）

适用对象：以内容分发与订阅为核心的应用。

级别	邮件
必备	邮箱验证、密码重置、欢迎邮件（非推广）、订阅确认
可选	OTP/2FA 验证码、账户更新通知

3. 电商 / 市场平台（E-commerce / Marketplace）

适用对象：用户购买产品或服务的应用。

级别	邮件
必备	邮箱验证、密码重置、欢迎邮件（非推广）、订单确认、发货通知、发票/收据、支付失败通知
可选	OTP/2FA 验证码、安全告警、订阅确认（针对定期订单）

4. SaaS / 订阅服务（SaaS / Subscription Service）

适用对象：有付费订阅等级和持续计费的应用。

级别	邮件
必备	邮箱验证、密码重置、欢迎邮件（非推广）、OTP/2FA 验证码、安全告警、订阅确认、订阅续费通知、支付失败通知、发票/收据
可选	账户更新通知、功能变更通知（仅针对破坏性变更）

5. 金融 / Fintech 应用（Financial / Fintech）

适用对象：处理资金、支付或敏感金融数据的应用。

级别	邮件
必备	邮箱验证、密码重置、OTP/2FA 验证码（敏感操作强制要求）、全类型安全告警、账户更新通知、交易确认、发票/收据、支付失败通知
可选	欢迎邮件（非推广）、合规通知

6. 社交 / 社区平台（Social / Community）

适用对象：以用户互动和社区功能为核心的应用。

级别	邮件
必备	邮箱验证、密码重置、欢迎邮件（非推广）、安全告警
可选	OTP/2FA 验证码、账户更新通知、动态通知（提及、回复）

7. 开发者工具 / API 平台（Developer Tools / API Platform）

适用对象：面向开发者、提供 API 访问与集成的应用。

级别	邮件
必备	邮箱验证、密码重置、OTP/2FA 验证码、安全告警、API Key 通知（创建、过期）、订阅确认、支付失败通知
可选	欢迎邮件（非推广）、用量告警（接近限额）、功能变更通知

8. 医疗 / HIPAA 合规应用（Healthcare）

适用对象：处理受保护健康信息（PHI）的应用。

级别	邮件
必备	邮箱验证、密码重置、OTP/2FA 验证码（强制要求）、全类型详细安全告警、账户更新通知、预约确认
可选	欢迎邮件（非推广）、合规通知

注意（原文档 Note）：医疗类应用要求严格。邮件应尽量少包含 PHI（受保护健康信息），敏感信息通过链接引导至安全门户查看。

完整邮件目录：逐类拆解内容与最佳实践

以下逐条完整继承原文档 Full Email Catalog 中每类邮件的 When to send / Purpose / Content should include / Best practices。

认证与安全（Authentication & Security）

邮箱验证 / 账户验证（Email Verification）

发送时机：用户注册后或修改邮箱地址后立即发送。
目的：验证邮箱地址属于该用户。
内容应包含：清晰的验证链接或验证码；过期时间（通常 24–48 小时）；操作说明；链接被误点时的安全提示。
最佳实践：秒级送达；包含过期提示；提供重发入口；问题场景链接到支持渠道。

OTP / 2FA 验证码（OTP / 2FA Codes）

发送时机：用户请求两步验证时。
目的：提供时效性认证码。
内容应包含：醒目展示的 OTP 码；过期时间（通常 5–10 分钟）；安全警告；"非本人请求"时的处理说明。
最佳实践：立即发送；验证码字号大、易读；过期时间显著标注；警告用户不要分享验证码；提供"I didn't request this"（并非本人请求）链接。

密码重置（Password Reset）

发送时机：用户请求重置密码时。
目的：让用户安全地重置遗忘的密码。
内容应包含：带 token 的重置链接；过期时间（通常 1 小时）；安全警告；"非本人请求"时的说明。
最佳实践：立即发送；链接快速过期（1 小时）；如可获取，附带 IP 地址与位置信息；提供"I didn't request this"链接；不要包含旧密码。

安全告警（Security Alerts）

发送时机：发生安全相关事件时（新设备登录、密码修改等）。
目的：向用户通报账户安全事件。
内容应包含：发生了什么（清晰描述）；发生时间；如可获取的位置/IP；如属异常应执行的操作；指向安全设置页的链接。
最佳实践：立即发送；表述清晰具体；包含可执行步骤；提供上报可疑活动的途径。

账户管理（Account Management）

欢迎邮件（Welcome Email）

发送时机：账户创建并验证成功后立即发送。
目的：欢迎新用户并引导下一步（必须是事务性的，不得推广）。
内容应包含：欢迎语；核心功能或下一步指引；重要资源链接；支持联系方式。
最佳实践：在邮箱验证之后再发；聚焦可操作信息，不堆砌；不过度信息轰炸；提前说明未来会收到哪些邮件、设定预期。

账户更新通知（Account Update Notifications）

发送时机：用户修改账户设置（邮箱、密码、资料等）时。
目的：确认账户变更并提供安全提示。
内容应包含：变更了什么；何时变更；如属未授权操作应采取的措施；指向账户设置的链接。
最佳实践：变更后立即发送；具体说明变更内容；包含安全提示；必要时提供便捷的撤销方式。

电商与交易（E-commerce & Transactions）

订单确认（Order Confirmations）

发送时机：订单创建后立即发送。
目的：确认订单详情并提供收据。
内容应包含：订单号；所购商品及数量；价格明细；收货地址；预计送达日期；订单跟踪链接（如可用）。
最佳实践：下单后数分钟内送达；包含完整订单详情；便于打印或保存；提供客服联系方式。

发货通知（Shipping Notifications）

发送时机：订单发货时，并随跟踪状态更新。
目的：告知用户订单已发货并提供跟踪信息。
内容应包含：订单号；跟踪号；承运商信息；预计送达日期；跟踪链接；收货地址确认。
最佳实践：发货时发送；跟踪号显著展示；提供承运商跟踪链接；在关键跟踪节点更新。

发票与收据（Invoices and Receipts）

发送时机：支付处理完成后。
目的：提供支付确认与收据。
内容应包含：发票/收据编号；支付金额；支付方式；所购商品/服务；支付日期；可下载 PDF（如适用）。
最佳实践：支付后立即发送；包含全部支付细节；便于下载保存；如适用包含税务信息。

订阅与计费（Subscriptions & Billing）

订阅确认（Subscription Confirmations）

发送时机：用户订阅或变更订阅时。
目的：确认订阅详情与计费信息。
内容应包含：订阅套餐详情；计费金额与周期；下次计费日期；支付方式；管理订阅的链接。
最佳实践：订阅后立即发送；清晰说明计费条款；提供便捷的取消入口；包含支持联系方式。

订阅续费通知（Subscription Renewal Notices）

发送时机：订阅续费前（通常提前 3–7 天）。
目的：提醒用户即将续费与扣款。
内容应包含：续费日期；扣款金额；当前绑定的支付方式；更新支付方式的链接；如希望取消的入口。
最佳实践：预留足够提前量（3–7 天）；金额与日期表述明确；便于更新支付方式；提供取消选项。

支付失败通知（Payment Failed Notices）

发送时机：订阅支付失败时。
目的：通知用户支付失败并提供解决步骤。
内容应包含：发生了什么；失败的金额；失败原因（如可获取）；解决步骤；更新支付方式的链接；不解决的后果。
最佳实践：失败后立即发送；明确说明后果；提供低门槛的解决路径；包含支持联系方式。

通知与更新（Notifications & Updates）

功能公告（事务性，Feature Announcements）

发送时机：用户正在使用的某个功能发生重大变化时。
目的：通知用户影响其使用的变更。
内容应包含：变更了什么；对用户的影响；需要采取的操作（如有）；更多信息链接。
最佳实践：仅限重大变更；聚焦用户影响；提供清晰的下一步；链接到文档。

注意（原文档 Note）：一般性的功能公告属于营销邮件。只有当变更直接影响用户正在使用的活跃功能时，才应以事务性邮件形式发送。

在 Novu 中落地这份目录：从规划清单到工作流

规划完邮件清单之后，目录中列出的每一类邮件在 Novu 中都对应一条工作流（workflow）加一次事件触发（trigger）。仓库内的官方指南给出了完整的实现路径，可作为目录与代码之间的衔接：

创建工作流：在 Novu Dashboard 中为每类邮件创建一个 workflow（如 password-reset），用 email 步骤承载正文，通过 {{payload.xxx}} 模板变量注入订单号、重置链接等数据（参见事务性通知指南）。
触发工作流：业务事件发生时从后端调用 trigger API。Node.js 示例（继承自官方指南）：

import { Novu } from '@novu/api';

const novu = new Novu({ secretKey: process.env.NOVU_SECRET_KEY });

await novu.trigger({
  workflowId: 'order-shipped',
  to: { subscriberId: 'user_123' },
  payload: {
    orderId: 'ORD-456',
    trackingUrl: 'https://example.com/track/456',
  },
});

对应的 cURL 形式为 POST /v1/events/trigger，携带 name（工作流标识）、to（订阅者）与 payload。从源码看，该接口由 events 控制器实现，内部通过 TriggerEventRequestDto 解析请求，并经由 ParseEventRequest、ProcessBulkTrigger 等 usecase 完成事件解析与分发；触发时若 subscriberId 尚不存在，Novu 会自动创建或更新订阅者，因此目录中的每类邮件都不要求预建订阅者。

多通道与降级：目录中"Payment failed"一类高时效性告警，官方指南建议采用 Email + in-app、并以 SMS 作为降级的通道组合（见事务性通知指南的通道推荐表）；密码重置场景还可叠加一个可选的 Throttle 步骤防止滥用，并用 in-app 步骤在应用内二次确认（见密码重置指南）。该指南还给出了一条重要的安全边界：不要在 Novu 中存储重置 token——token 的生成与校验保留在你的认证系统内，只把 resetUrl 和元数据作为 payload 传给 Novu。
通道配置：邮件步骤可对接 SendGrid、Postmark、Amazon SES 等已有 ESP，目录中的"立即发送"要求依赖你在集成商店中配置好发送提供方后由 Novu 工作流调度完成。

边界判断：为什么目录反复强调"必须非推广"

目录中几乎每处欢迎邮件、功能公告条目都标注了"must not be promotional"。这条约束的根源在邮件类型说明：事务性邮件是"用户发起或预期、用于完成一次交易或法律告知"的邮件，可以无需显式订阅而发送，但不得夹带推广内容；混合邮件（如新闻简报里塞入订单状态）应尽量避免，事务与营销邮件建议拆分发送子域（如 t.yourdomain.com 对 m.yourdomain.com）以隔离送达率与合规风险。这解释了目录为什么把"功能公告"单列为灰色地带：只有影响用户正在使用的功能时才算事务性。

发送侧最佳实践：目录之外的配套约束

目录回答"发哪些、发什么"，同技能包下的事务性邮件最佳实践回答"怎么发才能被打开并执行"，两者配套使用：

主题行具体化：Reset your password for [App] 优于 Action required；Your order #12345 has shipped 优于 Update on your order——订单号、账户名、过期时间都应进入主题。
预标题（Pre-Header）：90 字符以内，用于强化主题（如"This link expires in 1 hour"）。
移动端优先：60% 以上邮件在移动端打开；单列布局、按钮最小 44x44px、正文最小 16px；OTP 码用 24–32px 等宽字体居中展示并附过期说明。
发件人配置：From Name 用应用名且保持一致；From Email 用真实子域地址；Reply-To 指向有人监控的邮箱；避免 noreply@——用户会回复事务性邮件。
错误处理：重发需 60 秒冷却并限频（如每小时 3 次）；过期链接要给出明确"已过期"提示与重发入口；密码重置、OTP 与安全告警必须内置"I didn't request this"入口并记录点击用于监控。

小结与相关资源

这份目录的价值在于把"事务性邮件规划"从经验判断变成了可核对的清单：先用 8 类应用组合确定必备/可选范围，再按每类邮件的 When / Purpose / Content / Best practices 四要素逐封设计，最后通过 Novu 的工作流与 trigger API 落地为多通道发送。