简介：工作流引擎是企业系统自动化的核心组件，而“请假审批”是最典型的入门与实战场景。理解流程定义、节点与网关原理，能帮助开发者掌握状态流转、任务分配和条件分支等基础能力。在工程实践中，合理设计BPMN模型、配置排他网关与会签节点，可显著降低流程卡死、任务丢失及条件失配等风险。本文以可落地的请假流程为例，从流程拆解、XML定义到异常分支处理，系统梳理了请假实例的建模要点与常见坑位，并给出生产环境下的监控与捞单策略，帮助团队构建稳定、可维护的审批流程系统。
1. 工作流请假实例：为什么一个“申请+审批”会卡住整个团队
“工作流请假实例”是很多团队第一次接触工作流引擎时的入口需求，也是最能暴露流程设计问题的场景。表面看，请假就是“填单→审批→销假”，但落到系统里会遇到一连串问题：审批人离职了单子卡住、转交权限没配、半天假和年假跨天怎么算、打回之后子流程怎么恢复。这些细节在官方示例里几乎不会出现，真正踩过坑的开发者都明白，请假实例不是拿来演示的玩具，它是理解流程状态机、任务分配、会签与或签、条件分支的最佳试验场。
这篇文章不讲框架源码，也不罗列概念，而是围绕一个可落地的请假流程，从流程定义、数据建模、任务分配、会签与条件表达式，到边界场景的避坑，逐步拆开讲。新手可以照命令走，熟手可以重点看参数和异常分支的处理方式。核心思路一句话：流程引擎的价值不在“能发起一个申请”，而在“异常发生后，流程还能按预期走完”。
2. 先看流程怎么拆：请假实例里的节点、网关与表达式
2.1 一张请假单背后至少要有六个节点
一个能真实上线的请假流程，通常不会是简单的一条直线。常见做法是不小于以下节点：发起申请、直属主管审批、部门经理审批、人事备案、抄送通知、销假归档。每个节点都由事件触发，节点之间通过连线表达流转方向。
我一般会在流程设计器里先画“正向主链”，再补“异常分支”。正向主链解决的是“一切正常时怎么走”，异常分支解决的是“谁不同意、谁转交、谁撤回”的问题。请假实例里最容易遗漏的节点是人事备案和销假归档，前者影响考勤数据是否更新到工资计算，后者影响流程实例是“已结束”还是长期挂在“运行中”列表里。
节点设计阶段就要确定每个节点的办理人规则。直属主管可以按“发起人的部门主管”动态解析，人事备案可以按固定角色解析，抄送通知则无需办理人，只向相关人员发送消息。流程定义文件里，这些信息会体现为assignee、candidateUsers、candidateGroups之类的字段，写错了就会导致任务分配不到人。
2.2 网关选择：排他网关、并行网关与包容网关各归各位
请假流程里最常用的网关是排他网关，用于判断请假天数是否超过阈值，从而决定是“主管直接批准”还是“升级到部门经理审批”。排他网关必须有明确的条件表达式，否则会出现流程走到网关处卡死或随机选择分支的问题。
并行网关在请假实例里主要用在“人事备案”和“抄送通知”同时发生的情形。这两个节点没有先后依赖，完全可以用并行网关并行执行，节省整体审批时间。包容网关则适合“满足任意条件即触发”的场景，比如“请假超过三天”和“请假类型为事假”时都走特殊审批分支，但两个条件都不满足时走默认分支。
选择网关时还要注意网关的收敛方式。并行网关必须等所有并行分支都到达后才能继续往下走，如果有一个分支配置错误或没有到达，整个流程就会卡在网关处。这是请假实例里最典型的“看起来简单、跑起来翻车”的位置。
2.3 条件表达式：用流程变量驱动分支走向
条件表达式是请假流程的灵魂。常见的做法是在发起申请时收集表单数据，写入流程变量，然后在排他网关上用表达式判断分支。例如请假天数存储在变量days中，表达式可以写成${days >= 3}，分支指向部门经理审批，反之指向直接通过。
这里最容易犯的错误是变量类型不一致。表单组件返回的是字符串，表达式里按数值比较，结果永远是false。我习惯在流程启动前做一个类型转换，或者在后端代码里把字符串数字转换成Integer或Long后再放入流程变量。另一个常见错误是变量名大小写不一致，流程定义里写的是days，启动时放入的是Days，表达式永远匹配不到。
条件表达式的可读性也要注意。项目里常见的是流程定义里写了一段很长的表达式，后续维护时根本没人敢动。我一般会把表达式拆成短句子，每行一个条件，或者在流程变量里预计算一个布尔值，表达式只做布尔值判断。
3. 把请假流程定义落地：BPMN文件的写法和参数说明
3.1 一个可用流程定义文件的骨架
明确了上面的逻辑之后，落地就是编写流程定义的XML文件。以下是一个简化但完整的请假流程描述，使用通用工作流的BPMN表达。完整定义去掉一些边框之后核心骨架如下：
<definitions id="leaveProcess" targetNamespace="http://leave.process"> <process id="leaveProcess" name="Leave Process" isExecutable="true"> <startEvent id="startEvent" name="Start" /> <userTask id="applyTask" name="Apply Leave" assignee="${initiator}" /> <exclusiveGateway id="daysGateway" name="Days Gateway" /> <userTask id="supervisorApproval" name="Supervisor Approval" candidateUsers="${supervisor}" /> <userTask id="managerApproval" name="Manager Approval" candidateUsers="${manager}" /> <serviceTask id="postToHR" name="Post to HR" implementation="delegateExpression" delegateExpression="${hrDelegate}" /> <endEvent id="endEvent" name="End" /> <sequenceFlow id="flow1" sourceRef="startEvent" targetRef="applyTask" /> <sequenceFlow id="flow2" sourceRef="applyTask" targetRef="daysGateway" /> <sequenceFlow id="flow3" sourceRef="daysGateway" targetRef="supervisorApproval"> <conditionExpression xsi:type="tFormalExpression"> <![CDATA[${days < 3}]]> </conditionExpression> </sequenceFlow> <sequenceFlow id="flow4" sourceRef="daysGateway" targetRef="managerApproval"> <conditionExpression xsi:type="tFormalExpression"> <![CDATA[${days >= 3}]]> </conditionExpression> </sequenceFlow> <sequenceFlow id="flow5" sourceRef="supervisorApproval" targetRef="postToHR" /> <sequenceFlow id="flow6" sourceRef="managerApproval" targetRef="postToHR" /> <sequenceFlow id="flow7" sourceRef="postToHR" targetRef="endEvent" /> </process> </definitions>这段定义处理了“三天以内主管审批，三天及以上升级到经理审批”的经典分支。启动流程时，initiator、supervisor、manager、days会成为流程变量，条件表达式在网关处读取这些变量决定走哪条线。
3.2 各节点字段的语义与常见坑位
用户任务的assignee直接指定一个办理人，适合发起人固定的场景。candidateUsers指定一组候选办理人，组内任意一人认领后可办理，适合主管审批这类需要主动认领的环节。candidateGroups则按角色组分配任务，适合人事备案这类对公不对人的场景。
服务任务在这段定义里没有指定实现类而是用了委托表达式${hrDelegate}，意思是调用某个Bean封装的方法。这样做的好处是人事备案逻辑（写考勤表、更新休假额度）可以写到Service层，流程与业务逻辑解耦。坏处是Bean名称必须与容器中的Bean定义一致，否则启动时找不到Bean，流程实例会抛异常悬在那里。
流程实例启动后，各任务的id会作为运行时任务ID。开发时要根据taskId执行完成操作，而不是直接按流程节点名操作。这是一个高频踩坑位，很多人按流程定义里的名字去查任务，查不到就怀疑流程没启动。
3.3 流程实例的启动与推进命令
用通用工作流API启动一个请假流程实例，典型代码如下：
ProcessInstance processInstance = runtimeService .startProcessInstanceByKey("leaveProcess", variables); Task task = taskService.createTaskQuery() .processInstanceId(processInstance.getId()) .taskDefinitionKey("applyTask") .singleResult(); taskService.complete(task.getId(), taskVariables);启动时全靠variables这个Map把表单数据传进去。这里有一个老手都会检查的地方：第一次complete时传入的taskVariables会覆盖流程变量中同名变量的值，如果不注意，可能在第二步审批时就改写掉了第一步原本写入的数据。
推进流程时要特别注意当前节点是否真的是预期节点。createTaskQuery的taskDefinitionKey可以精确到某个节点，但流程如果因为条件分支走了不同的路径，这个查询可能查不到结果并返回null。稳妥做法是先用processInstanceId查询所有活动任务再逐个校验，而不是一上来就按定义里的节点名查。
3.4 设置流程变量与局部变量的边界
流程变量和任务局部变量的作用域不同。流程变量给整个流程实例使用，条件表达式、服务任务都可以读到。任务局部变量只对当前任务有效，任务结束时自动清除。
请假实例里比较常见的做法是：发起时写入days、leaveType等全局变量，审批意见和审批人等丢到任务局部变量里。好处是完整流程结束后，可以做流程实例级别的归档，避免审批意见与流程节点互相污染。
一个反复出现的错误是，在服务任务里读取任务局部变量，发现读取为空。这就是作用域不清造成的。服务任务执行时能读流程变量，但读不到其他任务的局部变量。如果你需要在后续节点读审批意见，就把审批意见存成流程变量，局部变量读不到的。
4. 子流程与会签：多角色审批的正确姿势
4.1 多级审批的两种建模方式
请假实例中多级审批有两种常见建模方式。第一种是串行节点，一级批完自动流向下一级，适合层级分明、前后依赖强的场景。第二种是子流程封装，把“部门内部审批”整体打包成一个子流程，外部看是一个节点，内部可以继续画多级。
我倾向于用子流程处理“部门内部审批”这类可复用逻辑。项目里如果多个流程都需要“部门审批”环节，这个子流程可以直接被复用。子流程内部还可以有独立的变量与网关，不会污染主子流程的变量，维护时只改子流程，外部流程完全不需要动。
子流程的另一个好处是权限控制。子流程内的任务可以单独授权给子流程范围的办理人，不会把权限扩散到整个主流程。比如部门审批子流程只允许本部门角色参与，主流程中的其他人即使有流程查看权限，也看不到子流程内部的任务细节。
4.2 会签实现：多人审批逐个通过
会签是请假流程中“多人同时审批”的常见场景，比如部门内多个负责人需要依次同意。通用工作流库里实现会签，常见做法是在用户任务上配置multiInstanceLoopCharacteristics，并指定集合与完成条件。
<userTask id="multiTask" name="Multi Approval" assignee="${assignee}"> <multiInstanceLoopCharacteristics isSequential="true"> <loopCardinality>3</loopCardinality> <loopDataInputRef>assigneeList</loopDataInputRef> <inputDataItem name="assignee" /> <completionCondition>${nrOfCompletedInstances >= 2}</completionCondition> </multiInstanceLoopCharacteristics> </userTask>这个配置表示该节点会循环生成三个子任务，三个任务分别分配到assigneeList里的三个人。completionCondition写“已完成实例数大于等于2”，意思是有两个人同意后该节点即算通过，第三个任务会被自动取消。这是和签的场景，只要两个人批就能放行。
4.3 或签与一票否决的实现差异
或签场景只需要一个人审批通过即可继续，可以把completionCondition改成${nrOfCompletedInstances >= 1}。一票否决则需要反着思考：任何一个审批人否决都让整个节点结束，通常的写法是把否决作为一种特殊事件由任务监听器处理，或者把完成条件做成${nrOfCompletedInstances >= nrOfInstances}并让每个任务只能通过或驳回。
这里要特别注意并行与串行的差异。上面示例中isSequential为true，是串行会签，一个一个来。如果改成false，就变成并行会签，所有子任务同时产生，各办各的。并行模式下，完成条件判断的时间点不固定，可能出现一个否决和一个同意同时发生，完成条件结果不确定的情况。
我在并行会签里会比较谨慎，先明确业务规则是“全部通过才通过”还是“多数通过就通过”，再去配置完成条件。若规则复杂，宁可在外部做完成后的事件监听做二次判断，也不要硬堆表达式。
5. 请假实例避坑指南：任务丢失、网关卡死与条件失配
5.1 任务丢失：审批人离职或被移除后节点无人处理
现象：流程走到主管审批节点，系统显示该节点有一个待办任务，但所有办理人列表里都查不到这个任务。
原因：任务分配到已离职人员的账号上，任务表里保留了assignee信息，组织账号被禁用后，任务不会自动重新分配，流程实例就像被冻住一样停在那里。
解决：在流程启动时就把“当前审批人”绑定成角色组而不是个人。主管审批用candidateGroup指向“部门主管”角色组，并配置任务监听器，办理人变更后自动Reassign。如果已经卡住，应急手段是手动调用runtimeService的setAssignee把任务转给当前在职主管，同时让原审批人的任务自动失效。
这种坑在内部系统里很常见，因为组织架构数据更新总比人员流动慢半拍。最好的防线不是出了问题再捞人，而是从一开始就不把个人账号写死在流程定义里。
5.2 网关卡死：条件分支没有匹配到任何路径
现象：流程走到排他网关后就没有下文，流程实例一直处于等待状态，待办列表里也是空的。
原因：网关所有分支的条件表达式都判断为false，而且没有配置默认分支。排他网关不会自动选一条没有条件的线走，如果所有分支都不满足，流程就会卡在网关上。
解决：每个排他网关都要配置一个默认分支。条件表达式设计时预留兜底逻辑，例如“其他情况”走默认审批路径。同时在网关前后加一个事件日志，每次走到网关时记录当前流程变量的值，方便事后排查。不要过度相信测试环境覆盖到的“三天阈值”用例，真实场景里会出现小数天、负数天、特殊请假类型等不在预期内的数据。
5.3 条件失配：字符串与数字类型不匹配
现象：表单里选了“3天”，提交后流程直接走了“大于等于三天”的分支，但另外一次选了“5天”却走了“小于三天”的分支，两个结果完全相反。
原因：表单提交的值是字符串，但表达式按数字比较，或者流程变量里存的对象与表达式里的取值路径不匹配。取错字段也会导致相同现象，表达式里写的是days，变量里其实叫dayCount。
解决：在流程启动前统一做数据清洗与类型转换。表单提交后先转换成Integer再放入变量。表达式只使用统一定义的变量名，禁止一处用驼峰一处用下划线。条件表达式里不要做过于复杂的嵌套逻辑，拆成多个简单表达式更直观。
这种类型失配问题早期在本地开发时往往测不出来，因为自己提交的数据类型都是正的，换个人提交就翻了车。
5.4 抄送任务变待办：通知节点被误建成办理节点
现象：流程中“抄送给人事”的节点被配成了用户任务，人事账号收到了待办提醒，但点进去没有任何可操作的按钮，只能填写无意义的备注才能归档。
原因：建模时把“通知”类的节点错建成了用户任务。抄送本质是消息推送，不应该生成待办任务。
解决：把这类节点改成服务任务或事件任务，内部只发送站内消息或邮件，不生成任务实例。如果一定要保留用户可查看的痕迹，可以通过业务消息表记录通知记录，不进入任务表。通俗地讲，抄送是群发消息，不是让收件人办手续。
5.5 驳回后重走：打回发起人修改后再次提交流程丢失
现象：审批人把申请驳回给发起人，发起人修改后再次提交，流程却直接结束了，没有重新走审批链。
原因：驳回操作通常只是把流程实例抛回上一个节点，但发起人修改后没有让流程变量里的原值全部刷新，部分审批节点因条件已满足而被网关跳过。
解决：驳回时清空该节点之后所有已产生的流程变量，重新提交时重新写入审批相关数据。流程建模上可以在驳回分支加一个“重新提交”网关，强制让流程重新进入审批链。更稳妥的做法是驳回不是真正的“回到上一步”，而是结束旧流程实例、发起新流程实例，旧实例保留在历史表里以作追溯。
6. 进阶：用手动捞单工具和流程事件监听器守住生产环境
请假实例上线之后，最先暴露问题的不是流程本身，而是无人关注的那些“卡在中间状态”的实例。我自己的习惯是维护一个简单的捞单脚本，定时扫描所有处于等待状态的流程实例，核对等待原因，并把异常实例的状态快照打出来。这个脚本不复杂，但每次出问题都是靠它找出卡点。
脚本用定时任务调用RuntimeService的活动实例查询接口，循环所有卡住的流程实例，检查它们停留在哪个节点。
curl -X GET /api/runtime/process-instances?active=true curl -X GET /api/runtime/activities/{processInstanceId}把两个接口的结果交叉比对，如果一个流程实例没有任何活动任务也没有任何活动执行，那一定是被网关卡住或等待一个不存在的信号事件。捞单脚本会生成一张“疑似僵尸实例”清单，运维只需检查清单即可。
另一个更有效的手段是在流程引擎里注册全局事件监听器。监听器捕获任务创建、任务完成、流程结束三类事件，统一把信息打到监控日志，形成流程轨迹。这样即使流程没有卡住，也能在做业务回溯时找到“到底谁在哪个时间点做了什么决定”。
事件监听器在代码里注册时，注意监听器的类型要覆盖到引擎内部事件，否则任务监听器只监听任务相关事件，流程实例的启动与结束事件不会被捕获。很多人一开始只监听了任务事件，结果流程结束后一点痕迹都没有，排查时非常被动。
关于请假实例的字段设计，还有一个容易被忽视的点：把“请假开始时间”和“请假结束时间”直接存成时间戳还是字符串，会影响跨天、跨月的数据统计。我一般建议统一存储为UTC时间戳，前端展示时换算成本地时区，否则到了分布式部署或跨时区协作时会漏出问题。请假天数不要依赖前端计算后传入后端，后端要根据起止时间重新计算，防止前端计算结果偏差导致审批规则被绕过。
做流程引擎项目，最深刻的教训就是“流程定义是死的，流程实例是活的”。同一个请假流程，在不同组织架构、不同时间段、不同人员状态下，跑出来的行为千差万别。提前把异常分支、类型转换、任务分配边界想清楚，能省掉大量上线后的临时救火。希望这套从建模到落地的思路能帮到你。
本文还有配套的精品资源，点击获取
