Dify工作流节点失败时可通过error_handler配置fallback_node跳转或fallback_value静态响应。需确保fallback_node为流程中真实存在的节点ID，大小写敏感；fallback_value则直接返回指定字符串作为节点输出。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当Dify工作流中某个节点因网络超时、模型API不可用或认证失效而失败时，必须立即启用备用逻辑保障流程不中断、结果可交付。
配置单节点fallback_node跳转
在目标节点的error_handler中直接指定失败后跳转的备用节点ID。
打开工作流JSON编辑器 → 找到出错风险高的节点（如http-request或llm调用）→ 在其config同级添加error_handler字段 → 设置strategy为"skip"或"fallback" → 指定fallback_node值为已存在的节点ID（如"cache_reader"或"static_response"）。
这一步不能填不存在的节点ID，否则工作流保存会报错且无法启动。【fallback_node值必须与流程中某节点的id字段完全一致，大小写敏感】
定义降级响应内容
方法一：使用内置fallback_value返回静态字符串
在error_handler中设置fallback_value:"服务暂不可用，请稍后再试" → 该值将作为该节点的输出直接传递给下游。
方法二：绑定专用降级节点执行动态逻辑
新建一个type为"code"的节点，命名为"local_fallback" → 在其config.script中编写Python逻辑（如读取Redis缓存、拼接兜底文案、调用本地小模型）→ 确保该节点无外部依赖且执行耗时
注意：若fallback_node指向的节点自身也失败，Dify不会二次触发error_handler，流程将终止并标记为最终失败。
按错误类型分流处理
第一步：识别原始错误类型
Dify在节点失败后自动注入last_error变量，其中details字段包含HTTP状态码、异常类名或模型返回的error.code。
第二步：在fallback节点中做条件分支
使用code节点读取last_error.message → 用if-elif-else判断是否含"401"、"timeout"、"ConnectionError"等关键词 → 分别调用refresh_token、return_cache、send_alert等不同子逻辑。
第三步：确保所有分支都有明确返回值
每个elif块末尾必须有return语句，否则Dify会因无输出而中断流程；空return或None会导致下游节点收到null，可能引发后续校验失败。
启用全局降级兜底
在工作流根级配置fallback_strategy字段，值为"global_fallback" → 同时在workflow顶层定义一个id为"__global_fallback"的节点 → 该节点将在任意节点未配置局部error_handler且发生错误时被激活。
这一步是最后防线，务必保证__global_fallback节点极度轻量：仅返回固定JSON结构{"status":"degraded","data":null}，不发起任何网络请求或数据库操作。
