BPMN排他网关和并行网关怎么用？用分支与汇合检查流程

BPMN排他网关与并行网关的区别，在于“选一条”还是“都要做”。排他分支根据条件选择一条路径；并行分支让所有输出路径继续。汇合时区别同样重要：排他汇合不等待其他路径，并行汇合则要等各输入路径到达后才能继续。

画图时不能只选一个看起来合适的菱形，还要检查分出去的路径怎样回来。可以在 Boardmix 在线流程图画布上先整理任务与条件，再沿每条路径走读。本篇用同一参与方内部的稿件发布准备过程，说明两种网关及常见误配。

先看分支与汇合各自承担什么作用

排他网关常标为菱形中的“X”，也称XOR网关；并行网关标为菱形中的“+”，也称AND网关。标记表达的是流程控制语义，不是任务优先级或图形装饰。为方便评审，同一张图中的排他网关标记应保持一致。

网关只负责选择、分发或同步，不替人完成审批、计算或检查。“审核稿件”应是任务；任务产生审核结果后，网关再根据结果决定往哪里走。把“审核”直接写进一个菱形，会漏掉谁完成检查、依据什么形成结果。

排他分支：条件要清楚，也要处理缺失值

假设一份稿件已经确认类型，只有“长文”和“短讯”两种。前面的任务写“确认稿件类型”，后面的X网关按类型路由：长文走“编辑长文”，短讯走“编辑短讯”。两条路都完成后，可用一个X网关汇入共同的后续准备环节。

在这个正常场景里，每份稿件只经过其中一个编辑任务。因此，汇合处没有必要等待另一种编辑任务；那条路径根本没有启动。这里的X汇合表达“任一已选择路径到达，就继续”。

实际评审还要问：类型为空、拼写错误或后来新增第三种时怎么办？可以在进入网关前完成校验，也可以明确设置默认路径，将未匹配情况交给“核对稿件类型”，再返回确认。默认路径用于没有其他条件匹配的情况，不能只画一条没写条件的线就让读者自行猜测。

对业务图，尽量让分支条件互斥、覆盖已知合法值。若两条条件同时满足，不应把“系统总会替我选对”作为业务规则。具体执行引擎的求值顺序和异常处理需要另外确认；例如Camunda的排他网关说明明确区分条件路径、默认路径和未匹配情形。

并行分支：两项工作都需要，汇合才等待

稿件编辑完成后，需要完成“校对正文”和“检查配图授权”两项工作，二者都针对同一待发布版本。在本例中，两项工作可以分别开展，因此用“+”网关分出两条路径，再用“+”网关汇合，最后进入“提交发布确认”。

并行网关不判断哪一项更重要，也不因为一项先做完就跳过另一项。正文先校对完时，流程仍要等配图授权检查；配图先检查完时，也要等正文。分支启动后，实际何时有人开始处理，仍取决于人员、系统与任务安排。

这里画的是两项检查达到可进入下一步的正常路径。若校对发现问题，需要修改后复核；若没有配图授权，需要更换素材或补齐授权。应把这些退回规则进一步展开，不能将“检查动作做过了”直接等同于“检查通过”。正文修改影响图片含义或版本时，也要确认另一项检查是否仍适用于当前版本。

用一个流程位置标记帮助走读：X分支之后只有一条编辑路径在推进；进入“+”分支后则有两条活动路径；两项检查都完成，汇合处再放行一次。这个标记用于理解流程实例，不表示员工人数、线程数或文件副本数量。

两种误配，为什么会让流程卡住或重复

误配一：排他分支后，用并行网关收口

如果“长文／短讯”由X分支选择，却在两个编辑任务后用“+”汇合，这个简单流程就会等待两条输入。长文稿只走了长文分支，短讯分支没有启动，另一条输入不会到来。图看起来整齐，流程却缺少继续所需的到达条件。

修正不是随便增加一条跨线，而是回到业务含义：长文和短讯本来就是二选一，此处使用X汇合。若真实业务要求两种材料都制作，那前面的选择规则也要重新定义，不能只改末尾的符号。

误配二：并行分支后，用排他网关收口

如果正文校对与配图授权都启动，却在末尾接一个X汇合，先完成的那条会直接进入“提交发布确认”，不会等待另一条。后完成的路径到达时又可能触发一次后续处理。在本例没有其他阻断或终止逻辑的情况下，就会出现提前提交和重复提交。

两项都必须满足才能发布，应改成“+”汇合。下游防重复措施可以作为系统实现的一部分，但不能代替图中正确表达“等两项都完成”的业务要求。

这些判断针对这里的简单、无循环、成对分支流程。复杂模型中的中断、循环、子流程和其他网关会改变路径状态，不能只凭“前后符号是否相同”判断整张图正确。关键仍是每条输入为何会到达、哪些路径曾经被启动、后续任务应当执行几次。

拿具体情形走图，比只检查符号更有效

可以先用正常的长文、短讯两条路径验证主线，再补缺失类型和检查失败的情形。每次走读都说清“现在停在哪里、等待什么、下一步何时允许执行”，不要只让参与者确认“这张图看起来没有问题”。

在白板中分开任务、规则和待确认问题

先放任务，再放路由与同步网关：确认类型、两种编辑任务、两项检查、提交发布确认。把X和+标记保留在图形内部，条件文字放到对应分支附近；连线方向与标签不要靠颜色猜。图较宽时可按“编辑选择”和“发布前检查”分成两个相邻区域，但两区域之间的共同入口应清楚连接。

在图旁保留待确认项，例如稿件类型由谁维护、缺失时谁核对、改稿后怎样重新确认图片。讨论确认后更新对应任务和条件，不把未决定的规则藏在一条无标签连线里。

如果进一步涉及外部供稿方或版权方，再核对参与方边界；可参考BPMN消息流与顺序流的连接区别。跨参与方通信与同一流程内的分支同步是不同问题，不能用消息虚线代替本例的任务顺序。用于沟通的图形成后，若要部署到工作流引擎，还需校验可执行模型、任务实现和异常处理。