n8n 通知实作：为什么失败重试会把第一封邮件发两遍

一个小团队收集用户申请，再逐个发送确认邮件。某个地址临时失败了，打开邮件节点的重试开关，看起来就能补救。但它前面已经发成功的邮件，会不会再发一次？

这次实测里，答案是会。第一个地址被接收，第二个地址暂时被拒绝，节点重试后，第一个地址又收到一封。流程最终显示成功，两条应发送的申请，却出现了三封被接收的邮件。绿色的执行状态，并不代表业务结果正确。

实验于 2026 年 10 月 16 日进行，环境是 Windows 11、n8n 2.43.7、Node.js 24.19.0、独立 SQLite 和本地 SMTP 接收器。没有接客户名单、外部表单、在线表格或互联网邮件服务。本文说的“接收”是 SMTP 接收器接受邮件，不等于真正进了用户收件箱，更不等于用户已经阅读。

四条申请，只有两条应该发送

我们把输入做得足够小，不懂程序也能逐行检查：

这些都是虚构地址，使用不能正常投递的保留域名。校验节点只接受该域名和 REQ-1 这种申请编号，避免读者导入演练流程后误发给真实用户。这是实验保护条件，不是通用的邮箱校验规则。

去重节点只在处理这一批输入时记住申请编号，没有查任何永久记录。它能识别表中的重复行，但无法知道昨天是否已经发过。这不是同一种“防重复”。

两种重试方式，差别在哪里

第一种方案把两条有效输入直接交给邮件节点。节点最多尝试两次，中间等待一秒。本地接收器先接受第一个地址，再对第二个地址的首次尝试返回临时拒绝码 450。

失败后，节点重试整批输入。它没有撤销已经被接收的第一封邮件，也没有跳过那条已成功的输入。接收器最终记录：第一个地址两封，第二个地址一封。

第二种方案在邮件节点前加入 Loop Over Items，批大小设为 1。loop 出口接邮件节点，邮件节点再接回循环；done 出口接完成节点。邮件节点仍然最多尝试两次，但每次调用只接到一条输入。

这一次，第一个地址只被接收一次，第二个地址首次失败后单独重试，也只被接收一次。改变的是重试范围，不是凭空获得了“绝不重发”的保证。官方循环节点说明区分了 loop 与 done 出口。n8n 的多数节点本来就能处理多条输入；这里加循环是为了解决观察到的重试问题，不是所有流程都必须多加一个循环。

四次测试，失败结果也保留

连续执行测试使用同一个接收器。它只对重试地址的第一次尝试返回拒绝，所以两遍合计三次尝试，不是四次。始终拒绝测试则对两次尝试都返回 450，执行以失败结束。

不想看程序日志，可以先下载四项结果 CSV。想核对顺序，再看接收器事件记录和实验方法。这些是这一版本、这一输入和本地接收器的观察，不代表所有 n8n 节点、邮件服务或网络故障都具有相同行为。

不接客户账号，先做一遍演练

1. 下载未启用流程包，解压出 workflow.json，在自己的 n8n 中建立空白流程，通过流程菜单导入这个 JSON，不是导入 ZIP。保持未发布。文件没有账号凭据，也没有定时或网页触发器。包内另附方法与实测记录，也可以先查看原始 JSON再决定是否导入。
2. 打开 Synthetic form submissions，核对上面的四条输入，不要换成真实客户。执行后查看 Validate and deduplicate this batch 的输出：应该有两条 ready、一条 duplicate-in-batch 和一条 invalid。
3. 在 Send to test mailbox 选择自己控制的本地邮件捕获器凭据，不要选择真实邮件服务。下载文件故意没有预选凭据。我们使用同一台 Windows 主机上的 127.0.0.1:2525，没有认证和 TLS；如果 n8n 在容器内，127.0.0.1 指向容器自身，需要换成能访问捕获器的本地服务地址。绝不能把无认证接收器暴露到公网。
4. 如果没有本地捕获器，到这里停下，先检查我们的事件下载即可。普通捕获器往往接收全部邮件，能验证连线，却不会自动复现 450 故障。方法文件说明了实验接收器如何仅拒绝 retry 地址的首次尝试，以及始终拒绝 fail 地址。
5. 手动执行一次，查看拒绝分支、邮件节点的执行次数和接收器记录。不要只看流程是否变绿。在我们的故障条件下，每条有效申请应该各有一封被接收。
6. 再执行一遍，应该看到每条有效申请又发一次。这是流程局限，不是让你对真实名单不断重试。演练结束后删除测试 SMTP 凭据。

流程节点名保留英文，让文章步骤与导入文件一一对应。可以让 Codex 或 Claude 解释校验代码和节点连线，但要求它在演练阶段保留 .invalid 限制、手动触发器和不接生产凭据的边界。不要把账号密码贴进对话。

真正接表单前，还缺哪些环节

对低风险的内部自动化，最有用的改进不是加更多节点，而是按每条申请定义成功条件：无效输入要看得见，重试耗尽要有人知道。本文失败分支会停止执行，尚未接操作员告警，也没有后续恢复队列。

真实表单还需要稳定的申请编号和持久处理记录。简单地“查表格、发邮件、再标已发送”仍可能被两个并发执行同时通过；也可能在邮件被接收之后、标记写入之前崩溃。需要原子领取任务或队列、保留投递记录，对状态不明的任务先查再重发。这些是正式上线前的设计要求，不是本下载已经实现或测试的功能。普通 SMTP 并没有给这个流程提供业务上的恰好一次保证。

接真实邮件服务时，先用无附件、不含客户敏感信息的确认消息做验证。认证、TLS、限流、垃圾邮件过滤、退信和真正送达都要另测。不能把实验中的无认证配置照搬到互联网服务。

你是否真的需要 n8n

如果表单平台自带的确认通知已够用，优先用它，可以少维护一个服务。需要分支处理、可见的数据转换、连接多个自己掌控的系统时，n8n 才更有价值。对开发者，脚本也许更短；但实际负责运营的人仍需要能看懂日志、知道失败后怎么办。这些是选型取舍，不是本文做过的竞品跑分。

n8n 社区软件采用 Sustainable Use License，不是不受限的开源许可证。企业内部使用与把它托管后对客户出售，并不是同一授权问题；嵌入产品或转售前要核对适用条款，自托管也仍有机器、邮件和维护成本。n8n 仓库分析讨论更完整的采用条件。

这次实验提供的结论更窄，但可以核查：逐条循环修复了本次整批重试导致的重复发送，重复执行依然会重发。它足够改进一次演练，也足够提醒我们，还不能给它贴上“生产可用”的标签。