自动化流程真正的风险，不是某个节点偶尔报错，而是失败后没有被发现、重复执行或造成部分成功。鲁棒的异常处理机制，应把一次执行视为可追踪的业务事件：既要记录原始输入，也要明确流程停在哪一步、已经完成了什么、是否允许重新执行，以及最终由谁处理。

先建立完整的异常链路

一个可维护的流程至少包含四层：

1. 输入校验：表单提交后，先检查邮箱格式、必填字段、时间格式和长文本长度。异常数据不能直接进入邮件、任务或客户表。
2. 数据标准化：统一字段命名，邮箱转为小写，时间转为同一时区；原始数据保留，转换后的数据用于后续节点。
3. 业务分支：合格需求、待确认需求、明显无效或重复提交，应分别处理，不能让所有输入都走同一条路径。
4. 异常落库：记录发生时间、触发来源、原始数据、失败节点、错误信息和处理状态。

n8n 的 IF 或 Switch、Make 的 Router + Filter 都可以实现分支，但分支条件必须能解释。比如，需求类型符合范围且邮箱在最近 7 天未出现，才进入正常处理；条件不足则进入待确认路径，重复或无效数据只归档，不触发客户通知。

重点防止“部分成功”

自动化常见的隐性故障是：确认邮件已经发出，但任务创建失败；或者任务创建成功，后续记录没有写入。此时简单重跑整条流程，可能造成重复邮件和重复任务。

因此，每次执行都应拥有可识别的业务键，例如标准化后的邮箱与提交时间组合。创建任务前先检查是否已有对应记录，重跑时只补齐缺失步骤。通知、任务和异常记录最好分开处理，并在记录中标注各自状态，而不是只保存一个“成功”或“失败”。

工具自身的执行历史适合定位技术错误，但不足以回答“漏了哪些客户”。应把失败执行同步到自己的异常表或专用频道，并提供直达原始记录和任务的链接。这样，人工处理对象才能从“报错信息”变成清晰的待办。

重试必须有边界

网络波动或外部服务暂时不可用时，可以进行有限重试；但数据格式错误、字段缺失和业务条件不满足，不应反复重试。重试前要判断该步骤是否具有副作用，尤其是发邮件和创建任务。对于无法安全重试的步骤，应转入人工复核，而不是无限循环。

上线前应覆盖完整提交、缺失字段、重复邮箱、边界条件、错误邮箱和超长描述，并手动重跑一次历史数据，确认不会产生重复任务。运行一到两周后定期检查异常记录，持续修正高频故障。鲁棒性不是“永不报错”，而是失败可见、影响可控、恢复可操作。