工作流的循环，核心不是让流程“重复跑”，而是让一组动作在满足条件时反复执行，并在达到退出条件后停止。正确用法是先定义循环对象，再设置触发条件、处理动作、判断节点和终止规则，最后用小范围数据验证，避免流程重复执行、无限循环或误处理。

很多人第一次接触工作流循环，会把它理解成“把某个步骤重复几次”。这只是最简单的一种情况。更准确地说，循环是工作流中一段可被反复调用的路径：流程处理一条记录、一个任务或一批数据后，系统判断是否还有未完成对象，若有，就回到前面的处理节点；若没有，则结束流程。

例如，订单审核可以循环处理多个订单，内容发布可以循环检查每篇待发布内容，研发任务可以循环执行“提交代码—测试—修复—重新测试”，客户服务也可以循环进行“收集信息—判断问题—补充资料—再次确认”。它的价值不在于重复本身，而在于把重复性判断和处理动作固定下来，减少人工遗漏。

## 一、先判断：你的工作流是否真的需要循环

并不是所有重复动作都适合做成循环。很多流程看起来有多个相似步骤，实际却只是固定顺序执行。如果误把普通流程设计成循环，后续会出现结构复杂、条件难维护、问题难定位等情况。

判断是否需要循环，可以先看三个问题。

第一，流程中是否存在“同一类对象需要被反复处理”的情况。比如一批任务需要逐个检查，一组表单需要逐条审核，一份资料需要反复修改直到通过。这类场景通常适合循环。

第二，下一次处理是否依赖上一次处理的结果。如果每一轮处理后，系统都要根据结果决定“继续、重试、跳过还是结束”，循环会比单纯复制步骤更合适。

第三，循环是否存在明确的停止条件。如果不能清楚说明“什么时候结束”，就不应该直接配置循环。一个无法解释退出条件的循环，迟早会出现反复执行或流程卡死。

常见的循环可以分为三类：

| 循环类型 | 适用场景 | 常见判断方式 | 主要风险 |
|---|---|---|---|
| 遍历循环 | 逐个处理一批任务、订单、数据 | 是否还有未处理对象 | 漏处理或重复处理 |
| 条件循环 | 持续执行直到满足条件 | 状态是否达到目标 | 无限循环 |
| 重试循环 | 失败后重新执行某个动作 | 是否成功、是否超过次数 | 重复提交、重复通知 |

**遍历循环**最容易理解。系统拿到一批对象后，每次取出一个对象进行处理，处理完成后再取下一个。比如审批人需要逐项检查一批申请，或者系统需要逐条同步数据。

**条件循环**更适合过程性任务。比如测试未通过就继续修复，资料不完整就继续补充，库存低于阈值就继续补货。它关注的不是“还有几个对象”，而是“目标状态是否已经达成”。

**重试循环**只解决暂时性失败，不代表任何失败都可以重试。网络中断、服务暂时不可用、系统响应超时，可能适合自动重试；权限不足、字段错误、业务规则不通过，则应该转人工处理，而不是反复提交。

一个简单判断方法是：如果你能把需求描述成“对每一个对象做一次处理”，通常是遍历；如果能描述成“只要条件不满足，就继续处理”，通常是条件循环；如果能描述成“失败后最多重新做几次”，通常是重试循环。

## 二、设计循环时，必须先写清四个要素

工作流循环最容易出问题的地方，不是动作怎么配置，而是规则没有写清楚。建议在搭建流程之前，先把循环拆成四个要素：循环对象、进入条件、处理动作、退出条件。

### 1. 明确循环对象

循环对象可以是一条任务、一份资料、一个订单，也可以是一批记录中的单个成员。对象必须有稳定的标识，否则系统无法判断某个对象是否已经处理过。

例如，“处理所有待审核申请”是一个完整的循环对象定义；“处理申请”则不够具体，因为系统不知道处理的是哪一条申请，也不知道是否会重复处理同一条申请。

循环对象最好带有以下信息：

- 唯一标识，区分不同对象；
- 当前状态，判断是否已经处理；
- 上一次处理结果，决定是否继续；
- 尝试次数或处理时间，便于限制重复执行。

如果对象没有状态字段，可以考虑增加“待处理、处理中、已完成、失败、需人工介入”等状态。状态不是为了让页面更好看，而是为了让循环拥有可判断的依据。

### 2. 定义进入循环的条件

进入条件决定哪些对象可以被循环处理。条件越模糊，误处理的概率越高。

例如，不要只写“处理新任务”，而要明确“当任务状态为待处理、负责人已分配、必要字段已填写时，进入处理流程”。这样可以避免空任务、重复任务或资料不完整的任务被提前送入循环。

进入条件通常需要同时考虑业务状态和数据完整性。单纯判断“状态为待处理”可能不够，因为对象虽然处于待处理状态，但可能缺少金额、负责人、附件或审批信息。

### 3. 设计每一轮要执行的动作

每一轮循环必须有清晰的动作边界。动作过多，后续很难判断到底是哪一步导致失败；动作过少，循环又无法完成业务处理。

一轮处理通常可以拆为：

1. 获取当前对象；
2. 检查对象是否满足处理条件；
3. 执行业务动作；
4. 写入处理结果；
5. 更新对象状态；
6. 判断是否进入下一轮。

这里最关键的是“写入结果”和“更新状态”。如果动作做完了，但状态没有变化，下一次循环可能还会把同一对象当成未处理对象，再执行一遍。

例如，发送通知完成后，应当写入“通知已发送”或记录发送结果；数据同步完成后，应当更新同步时间或同步状态；审批提交成功后，应当改变审批节点，而不是只依赖系统是否返回成功提示。

### 4. 设置退出条件

退出条件决定循环什么时候结束，至少要明确以下一种或多种判断：

- 所有对象都已处理完成；
- 目标状态已经达到；
- 重试次数已达到上限；
- 超过规定时间；
- 出现必须转人工的异常；
- 数据不再满足继续处理条件。

最稳妥的做法是使用“正常退出”和“异常退出”两条路径。正常退出代表循环按预期完成，异常退出代表无法继续，但不能再重复执行。

例如，内容审核循环可以这样设计：通过则结束，未通过且仍有修改机会则返回编辑，超过三次仍未通过则转人工；支付确认循环可以这样设计：支付成功则结束，超时则重试，超过两次仍无结果则标记为待核查。

## 三、工作流循环的标准搭建顺序

一个稳定的循环，不是从“重复节点”开始配置，而是从业务结果倒推流程结构。建议按照“目标—对象—条件—动作—状态—退出—异常”的顺序搭建。

### 先确定循环要达成的结果

不要一开始就问“这个步骤怎么重复”，先问“循环结束时，我希望对象处于什么状态”。

例如，批量审核的目标是每条申请都有明确审核结果；研发修复流程的目标是问题通过验证或被转人工；资料收集流程的目标是资料完整并完成归档。

如果结果没有定义，循环就会变成无目的的反复执行。流程可能一直在发送提醒、检查状态或重新提交，但没人知道什么时候算完成。

### 再确定每轮只处理一个对象还是一批对象

处理一个对象的循环，通常更容易控制。系统每次只拿一条数据，完成后更新状态，再进入下一条。这样问题定位更清楚，也能减少并发冲突。

处理一批对象则适合动作本身支持批量执行的场景，例如一次更新多条记录、一次生成一批通知。但批量处理对失败管理要求更高：其中一条失败时，是整批回滚，还是只标记失败对象？如果没有明确规则，批量循环会让问题变得更复杂。

多数业务场景可以采用“外层批次、内层单对象”的方式：先确定需要处理的一批对象，再逐个处理，并为每个对象记录结果。

### 把判断节点放在关键动作之前

判断节点一般有两种用途：决定当前对象是否可以处理，或者决定本轮处理后是否继续。

例如，在发送提醒前，先判断对象是否已经完成；在重试前，先判断是否超过次数；在进入下一轮前，先判断是否还有未处理对象。

把判断放在动作之后，容易出现先执行、后发现不应该执行的问题。比如任务已经关闭，系统仍然先发出催办通知；订单已经取消，系统仍然继续扣减库存。

### 每轮结束时更新状态

状态更新是循环能否正常前进的关键。一个常见错误是只在整个流程结束时更新最终状态，而不在每轮处理后记录中间状态。这样一旦流程中断，系统无法判断哪些对象做过、哪些对象没做过。

更合理的状态设计可以包括：

- 待处理：尚未进入循环；
- 处理中：已经被某一轮获取；
- 已完成：本轮动作成功；
- 可重试：暂时失败，允许再次执行；
- 已失败：达到重试限制或数据错误；
- 待人工：自动规则无法判断或继续执行存在风险。

状态数量不宜过多。状态过少，无法支撑判断；状态过多，人员容易混淆。每个状态都应该能回答一个问题：当前对象接下来应该做什么。

## 四、用几个典型场景理解循环怎么用

### 场景一：批量处理待办任务

假设系统每天需要处理一批待办任务。流程可以从“获取所有符合条件的待办任务”开始，然后逐个取出任务。

每次循环先判断任务是否仍然有效。如果任务已经被人工处理、取消或转移，就跳过当前对象，避免重复动作。如果任务仍然有效，再执行分配负责人、发送提醒或更新状态等操作。处理完成后，把任务改为已完成，并记录处理时间。

这个场景的退出条件是“没有剩余待处理任务”。异常条件包括任务缺少负责人、对象被锁定、处理动作失败等。异常对象不应继续留在“待处理”状态，否则下一次运行还会重复进入循环。

### 场景二：表单资料补充

资料补充是典型的条件循环。系统收到表单后，先检查必填字段和附件是否完整。如果不完整，就通知提交人补充；提交人补充后，流程重新检查。

这里不能简单设置“每隔一段时间检查一次”，还要设置合理的退出规则：资料完整则进入下一节点，超过规定时间仍未补齐则转人工或标记为失效。如果提交人连续提交无效内容，也应该设置尝试次数或异常分支。

这个场景的关键不在于提醒多少次，而在于每次提醒必须指出缺什么、为什么需要补充，以及补充后如何重新进入检查节点。否则循环只是重复发送同一条模糊通知，无法推动问题解决。

### 场景三：研发任务测试与修复

研发流程中常见“开发完成—测试—修复—再次测试”的循环。它不是简单的无限回到测试节点，而应当有明确的状态和边界。

测试通过，任务进入发布或验收；测试不通过，生成或关联缺陷，返回修复节点；修复完成后重新进入测试。若同一问题多次修复仍未通过，应当进入评审、升级或人工分析，而不是继续自动重复。

此类循环尤其需要记录每一轮的测试结果、失败原因和修复内容。没有历史记录，团队只能看到“现在未通过”，却无法判断问题是偶发错误、需求理解偏差，还是测试环境本身存在异常。

### 场景四：失败重试

重试循环必须限定对象、次数、间隔和失败类型。可以把它理解为一种受控补救，而不是无限补偿。

例如，系统调用外部服务失败时，可以短时间后重试一次；再次失败后延迟更长时间再试；达到上限后，记录错误并转人工。若返回结果明确表示参数错误，则不应继续重试，而应直接修正数据。

重试设计可以参考以下判断：

| 失败类型 | 是否适合自动重试 | 处理方式 |
|---|---|---|
| 临时网络中断 | 通常适合 | 延迟后重试，并限制次数 |
| 服务暂时繁忙 | 通常适合 | 逐步拉长重试间隔 |
| 参数格式错误 | 不适合 | 修正数据或转人工 |
| 权限不足 | 不适合连续重试 | 检查权限后重新发起 |
| 业务规则不通过 | 通常不适合 | 返回处理人补充或修改 |

如果动作本身不可重复，例如扣款、创建唯一订单、发送具有法律效力的通知，就必须先确认幂等性。所谓幂等，是同一个动作因为网络异常而被执行多次时，结果不会产生重复影响。没有这层保障，重试可能把一次操作变成两次扣款、两条订单或多封重复通知。

## 五、循环最容易卡在哪里，怎么处理

### 无限循环

无限循环通常有三种原因：退出条件永远无法满足，状态没有更新，或者流程每一轮都把对象重新放回了入口。

比如，条件写成“只要状态不是完成就继续”，但流程中没有任何节点能够把状态改为完成；或者每轮处理后只更新了处理时间，没有改变判断条件；又或者失败对象被重新标记为待处理，却没有累计失败次数。

解决方法是检查循环是否存在明确的“前进量”。每一轮之后，至少要有一个变化能够让对象更接近结束状态，例如剩余对象数量减少、状态向完成方向移动、尝试次数增加、截止时间缩短。

### 重复执行

重复执行不一定是无限循环，也可能是流程每次运行都重新处理已经完成的对象。最常见的原因是缺少唯一标识和处理记录。

例如，定时任务每小时扫描一次数据，如果筛选条件只是“创建时间早于当前时间”，那么旧数据会被反复取出。更合理的条件应当包含“处理状态不是已完成”，并在动作成功后及时写入处理标记。

对不能重复执行的动作，应当在执行前再次检查状态。即使入口节点已经判断过，经过排队、延迟或并发后，状态也可能发生变化。关键动作前的二次校验往往比事后补救更可靠。

### 循环阻塞

循环阻塞是指某一条对象一直停留在处理中，导致后续流程无法推进。原因可能是动作超时、人工长期未处理、外部服务无响应或锁未释放。

可以设置处理超时和接管规则。例如，进入处理中超过规定时间后，自动恢复为可重试；重试失败后进入待人工；人工节点超过处理时限后，提醒负责人或升级给上级。具体时长要根据业务风险设定，不同场景不宜使用同一套标准。

### 数据越处理越乱

循环会放大数据问题。字段格式不统一、状态值混乱、负责人缺失，可能只影响一条记录；一旦放进循环，就会批量产生错误结果。

因此，循环入口应当设置数据校验，至少检查必填字段、状态合法性和对象关联关系。对于无法自动修正的数据，不要让流程强行继续，应当进入异常队列，并保留原始信息和错误原因。

### 只关注流程成功，不关注业务成功

工作流显示“执行成功”，不代表业务已经完成。比如通知接口返回成功，但接收人没有收到；任务状态更新成功，但实际文件并未生成；测试节点执行完成，但测试结果本身是不通过的。

判断循环是否成功，必须使用业务结果作为依据，而不是只看节点是否运行完毕。流程日志可以证明“动作执行过”，业务字段则要证明“目标已经达成”。

## 六、上线前后的验证和维护方法

循环不适合一次配置后长期不管。上线前需要验证正常路径、异常路径和边界条件，运行后还要观察是否出现重复、漏处理和长时间停滞。

测试时不要只准备一条正常数据，至少应准备以下几类对象：

1. 完整且符合条件的对象，验证正常完成；
2. 缺少关键字段的对象，验证是否被拦截；
3. 已处理或已取消的对象，验证是否会重复执行；
4. 多次失败或超时的对象，验证是否能退出并转人工。

测试重点不是“流程能不能跑通”，而是确认每一轮的状态变化是否符合预期。可以逐步检查：对象何时进入循环、每次动作后状态是什么、失败后是否记录原因、重试次数是否增加、最终是否一定能进入某个结束状态。

对于涉及通知、扣款、库存、权限、数据删除等高风险动作，应当先在低风险数据范围内运行。不要一开始就让循环处理全部历史数据，也不要在没有审计记录的情况下开放自动重试。

运行一段时间后，可以重点观察四类指标：完成率、异常率、重试次数和平均停留时间。这里不一定要追求复杂统计，能回答“哪些对象最容易卡住”“哪些节点最常失败”“是否存在重复处理”就足够支持优化。

当业务规则发生变化时，优先检查循环的入口条件、退出条件和状态流转。很多流程不是动作变了，而是原来的“完成”定义变了。如果只修改通知内容，却没有调整判断规则，循环仍可能按照旧逻辑运行。

## 七、总结：把循环当成受控的重复，而不是无限回路

工作流的循环怎么用，关键在于把重复处理变成一条有边界的路径：明确循环对象，设置进入条件，执行单轮动作，及时更新状态，并为正常完成、失败重试、超时和人工接管分别设置出口。只要无法说清楚循环何时结束，就不应急着上线。

落地时可以从一个低风险、对象边界清楚的场景开始，例如批量处理待办或资料完整性检查。先验证状态是否前进、对象是否重复、异常是否可追踪，再逐步增加重试、并发和人工接管规则。一个好用的工作流循环，不是重复次数最多，而是能在正确条件下继续，在无法继续时及时停止。

当工作流需要对列表中的每条数据执行相同操作时，可以使用循环。例如，批量处理客户信息、逐条生成商品描述，或遍历文件并提取内容。

适合重复处理的数据和任务

什么情况下需要在工作流中使用循环节点？

工作流中的循环适合处理哪些任务？

在工作流中添加循环节点，选择需要遍历的数组或列表作为输入，再在循环内部配置处理单条数据的节点。连接所需的上下游节点后，使用测试数据检查执行结果。具体配置方式可能因平台而异。

设置循环数据和处理步骤

想让工作流逐条处理一组数据，需要设置哪些内容？

如何配置工作流的循环节点？

在循环内部配置节点参数时，选择循环节点提供的当前项变量。如果当前项是包含多个字段的对象，可以继续选择需要使用的字段，例如姓名、订单编号或文件地址。变量名称取决于所使用的平台。

引用当前循环项

在循环内部的节点中，怎样引用当前这一条数据？

循环节点如何获取当前处理的数据？

根据平台提供的功能，指定循环内部需要收集的输出字段，并将汇总后的列表传给下游节点。下游节点可以继续对结果进行筛选、拼接、保存或发送。

收集每次循环的输出

工作流逐条处理完数据后，怎样把所有结果交给后续节点？

循环处理后的结果如何汇总？

查看执行日志，定位报错的循环项和节点，检查数据格式、必填字段及接口调用情况。对于可能出现的异常，可以根据平台能力配置重试、跳过或错误处理分支，避免单条数据影响整个任务。

检查输入数据和错误记录

如果循环处理到某条数据时报错，应该如何排查？

工作流循环执行失败时该怎么办？

PingCodeDocs

工作流循环的正确用法，是围绕循环对象建立进入条件、处理动作、状态更新和退出规则，并区分遍历循环、条件循环与重试循环。落地时要重点防止无限循环、重复执行、流程阻塞和数据错误，通过状态管理、次数限制、超时处理和人工接管保证循环可控。