Dify工作流中的循环与迭代处理探索

最近不少朋友在群里问，在Dify工作流里处理多层嵌套数据时，到底该用循环节点还是迭代节点？比如要对用户订单列表逐个调用风控模型，再对每个订单内的商品明细做二次校验，配置不当就会出现数据错位、上下文丢失，甚至子项没法访问外层变量——这类问题还真不算少见。

要从根本上理清这两者，关键在于先吃透它们的适用场景。

区别循环节点与迭代节点的适用场景

循环节点（loop）更像是底层控制结构，功能全面，支持foreach/while/计数三种模式，可以嵌套，也能设置中断条件，变量名还能自定义。迭代节点（iteration）则可以理解为面向非技术用户的简化版，只支持foreach模式，自动绑定item变量，但不支持break_condition或自定义作用域。

换句话说，处理像["A","B","C"]这样的纯一维数组，而且不需要中断逻辑，用迭代节点更轻量省事；一旦涉及多层嵌套、需要根据某项状态提前退出，或者要复用外层变量名，那就必须选循环节点。

特别提醒一点：迭代节点的输入源

配置单层遍历：以用户列表触发批量推理

先说方法一，使用迭代节点，新手比较推荐。在工作流画布拖入「迭代节点」，双击打开配置面板，在「输入路径」填入inputs.users，确保上游节点已将用户数据以数组形式写入该路径。「当前项变量名」保持默认的item，后续子节点直接引用{{item.id}}或{{item.email}}即可。

方法二则是使用循环节点，适合需要控制流程的场景。在「循环模式」下拉选foreach，「输入源」填{{inputs.users}}，「当前项变量名」改为user，然后展开「高级设置」勾选「启用错误跳过」。改变量名为user而非item，是为了后续嵌套时避免与内层变量冲突；启用错误跳过能防止单个用户数据异常拖垮整个流程。

构建嵌套循环：用户→订单→商品三级处理

外层必须用循环节点，内层可以用迭代或者循环——但如果内层需要引用外层变量，两层都必须用循环节点并显式声明变量名。

具体配置分几步走：①外层循环选「循环节点」，「输入源」填{{inputs.users}}，「当前项变量名」设为current_user。②在外层节点的「分支」区域拖入第二个「循环节点」。③内层循环的「输入源」填{{current_user.orders}}，「当前项变量名」设为current_order——注意表达式必须用双大括号包裹，否则系统无法解析外层变量。④在内层分支中再加一层循环或迭代节点处理current_order.items，变量名依次设为product。

这里有个典型错误：内层输入源如果写成inputs.orders而不是{{current_user.orders}}，系统就找不到数据源，整个内层循环直接跳过不执行。

终止条件与动态退出实战

实现动态退出有两种常用方法。

方法一：在循环节点中配置break_condition。进入「高级设置」开启「启用中断条件」，输入表达式{{item.status == "blocked"}}，当任意一项状态为blocked时，迭代就会立即终止。

方法二：用条件判断节点配合循环结束节点。在循环体内部插入「条件判断节点」，判断逻辑设为{{item.risk_score > 95}}，「是」分支连接「循环结束节点」，「否」分支继续执行下游操作。注意，循环结束节点必须与当前循环节点配对使用，不能跨层级混用，否则工作流校验会失败。

调试与验证关键数据流

每层循环节点之后，建议插入一个「调试日志节点」，内容填外层用户ID: {{current_user.id}}，订单数: {{current_user.orders | length}}。运行测试时，先用固定三用户、每用户一订单的最小数据集验证路径是否畅通，确认无误后再逐步放大样本量。

如果日志中间出现undefined或空数组，第一时间检查上游节点输出是否为真实的数组类型。可以在前序节点末尾加一个「转换节点」，用表达式json_parse(inputs.raw_users)强制转为数组，这个细节往往就能解决问题。