错误拦截器需部署在每个潜在失败点前而非仅入口处；条件分支须为各分支首节点配置独立error_handler；并行分支需启用隔离模式并为每子流程单独设fallback；循环分支须在循环体内节点注入错误验证容错。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
多分支工作流中错误拦截器的核心定位
当Dify工作流包含条件判断、并行执行或循环节点时，错误可能发生在任意分支路径上，且上游节点失败会直接中断后续所有分支的触发，导致部分逻辑永远得不到执行验证。必须在每个潜在失败点前部署独立的错误拦截器，而非仅在流程入口处设置全局兜底。
为条件分支节点配置独立错误处理器
方法一：在每个 if/else 分支的起始节点手动添加 error_handler 字段
打开工作流编辑器 → 点击条件分支下的第一个节点（如“HTTP请求”或“脚本”）→ 展开「高级设置」→ 在 JSON 配置区粘贴以下结构：
【"error_handler": {"fallback_node": "branch_error_handler_1", "retry": 2, "delay_ms": 300}
注意：fallback_node 的值必须与你已在流程中创建的专用错误处理节点 ID 完全一致，大小写和下划线都不能错；若填错，系统不会报错但会静默跳过回退逻辑。
方法二：使用可视化拖拽方式绑定回退节点
先在画布空白处创建一个「调试节点」或「文本节点」，重命名为“分支1错误处理” → 选中该节点 → 右键菜单选择「设为回退节点」→ 返回条件分支内任一节点 → 在属性面板中点击「设置错误处理器」→ 从下拉列表中选择刚命名的节点。
并行分支中的错误隔离策略
第一步：确认所有并行节点已启用「独立执行模式」
选中并行容器节点 → 检查「执行模式」是否为「并行且相互隔离」；若为「串行依赖」或「共享上下文」，任一分支出错将导致整个并行组终止，无法实现真正的错误隔离。
第二步：为每个子分支单独配置 fallback 节点
并行容器内的每个子流程都应视为独立工作流，其内部第一个节点必须显式声明 error_handler；不能复用容器外的同一 fallback 节点，否则多个分支错误日志会混在一起，无法区分来源。
第三步：禁用跨分支状态传递
在并行容器的输出映射配置中，删除所有指向同一变量名的 merge 操作，例如避免将 branch_a.result 和 branch_b.result 同时写入 $output.data；这会导致某一分支失败后，另一分支的成功结果也被丢弃——Dify 默认只要任一输入缺失就清空整个输出对象。
动态循环分支的错误注入测试法
在正式上线前，必须对循环体内部节点做强制错误注入验证：
进入循环节点配置 → 找到「循环体」区域 → 在任意一个节点的脚本内容末尾添加一行：throw new Error("simulated_loop_failure");
保存并运行测试流程 → 观察日志中是否只中断当前迭代，而后续迭代仍能继续执行；若整个循环提前退出，说明 error_handler 未正确挂载到循环体内部节点，而是挂在了循环容器本身——这是常见配置错误。
这一步操作起来很简单，直接把 throw 语句加进去就行，但漏掉它就无法验证容错机制是否真实生效。
