BPMN网关控制流程的分流与汇合：排他网关在条件分支中选择一条路，并行网关启动全部分支并在汇合处等待各路，包容网关可以选择多条满足条件的路。选网关时先问“这几件事要做一件、全部做，还是按条件做几件”，再问“后续任务需要等哪些结果”。菱形画得相同，不代表执行含义相同。
例如采购申请通过资料检查后，财务审查与库存确认都要完成，才能形成采购决定。可以先用墨刀流程图梳理分支和汇合关系，把条件、责任与等待画在同一张画布上。这里讨论的是流程表达，流程引擎的执行能力与配置需要另行实现。
先用token判断流程走到了哪里
Token可以理解为沿流程移动的执行标记，用来推演当前有哪些路径处于活动状态。它不是业务单据，也不是一个员工。即使采购单只有一份，流程进入并行分支后，也可能同时存在财务和库存两条活动路径。
在纸上放一枚标记，从开始事件沿箭头移动。到排他分流时，标记只进入一条选定路径；到并行分流时，为每条后续路径放一枚标记；到需要同步的汇合处，按规则等相应路径到达。这种走图方式会暴露“有一条路永远不会来”的问题，而只看线条是否连通通常发现不了。
不要把并行理解为两个任务必须同一秒开始或由两条计算机线程执行。它表达的是两条路径都被启用，不依赖对方先结束。财务在上午处理、库存下午处理，也仍然可以属于同一段并行流程。
三种常用网关，区别首先在汇合
| 网关 | 分流时 | 汇合时 |
|---|---|---|
| 排他网关（X） | 选一条条件满足的路径；应处理无条件命中的情况 | 不做多路同步，任一路到达即可继续 |
| 并行网关（+） | 启动全部出路，不靠条件决定是否启动 | 等待各条入路的执行到达后再继续 |
| 包容网关（○） | 启动一个或多个条件满足的分支 | 在结构清晰的配对区域中，等待本次启用且会到达此处的分支 |
排他和并行的汇合规则可分别对照Camunda排他网关说明与并行网关说明。包容汇合涉及当前仍可能到达的活动路径，在复杂循环或非配对结构中不能只数图上有几根线；包容网关官方说明给出了更精确的等待条件。
一个实用反例是“财务、法务只要任意一方完成就继续”。这既不是普通并行汇合，也不能简单改成排他汇合：后到的另一条路径可能再次触发下游任务。“任一完成后其余是否取消”需要单独建模，不能靠换一个菱形省掉取消和后续结果处理。
用采购申请拆开条件判断和同时处理
本例只讨论一张采购申请：资料不齐全先补充；资料齐全后，财务核对预算，仓库确认库存；两项都形成结论后，再决定继续采购还是退回。金额和审查阈值由各自业务确定，这里不预设行业通用标准。
- 资料检查后放排他网关：菱形写“资料齐全？”，两条出线分别写“齐全”和“缺少必填资料”。缺资料去补充任务，补齐后回到资料检查，不直接绕过检查进入采购。
- 齐全路径进入并行分流：从“+”网关分别连到“财务审查”和“库存确认”。两项都必须做，不给其中一条加“有库存时才进入”的含糊条件。
- 两项结论进入并行汇合：每条分支都输出本次审查结果，再到同一个“+”汇合。此处只负责等任务完成，不负责判断两项是否通过。
- 汇合后再判断采购条件：排他网关根据预算结论与库存结果决定“生成采购单”或“退回调整”。把业务结果判断与流程同步分开，读者才能看懂为何已经汇合却还可能退回。
这张图最容易误画的地方是财务“不通过”直接连到普通结束事件，库存仍连到并行汇合。此时库存完成后会等财务路径，而财务已经离开；流程就可能卡住。本例的做法是让财务输出“通过/不通过”的审查结论后都到达汇合，再统一判断。
如果业务明确要求一方拒绝就立即停止其余审查，那是另一种规则：需要定义如何中断正在进行的分支、是否撤销已创建任务、如何保留已完成结论。应使用适当的事件或子流程取消机制表达，不能仅把拒绝箭头画向一个普通结束圆圈。
分支条件要让人看得出是否重叠、是否漏项
排他网关名可以是问题，但出线应写能够判断的条件。例如金额分支写“金额≤5000”和“金额>5000”，不要两边分别写“大额”和“普通”，让每个部门自行理解。5000只是本例的规则值，不是推荐审批标准。
若误写“金额≥5000”和“金额≤5000”，刚好5000会同时满足两条条件。不同执行环境或配置对命中顺序的处理不应成为业务规则。设计阶段就把条件写成互斥关系；另外检查金额为空、币种不一致、校验未完成等情况，必要时在网关前增加数据校验任务。
默认路径用于其他条件都未命中的情况，不是“通常走这里”的高亮路线。可以把它指向“人工核对”，但要说明为什么无法自动判断以及由谁接收。不要把默认分支当成无声批准，掩盖缺字段或规则遗漏。
对于包容分流，条件允许同时成立。例如合同评审中，“涉及个人信息”需要隐私评审，“涉及外币结算”需要财务评审；两项都命中就启动两项。条件均未命中时，走事先明确的默认路径，不能让流程无路可走。
包容网关适合可选任务，不适合隐藏复杂规则
包容网关常被概括为“几条都可以”，但真正困难的是后面等待谁。可选评审最好保持结构清楚：从一个包容分流进入若干独立任务，再到对应包容汇合；在图旁记录本次哪些条件会启用哪些分支。
以合同评审为例，只有隐私条件成立时，完成隐私评审后可以继续；隐私和外币条件同时成立时，需要两项都完成；不能让财务分支根本没被启动，汇合却永远等财务。这正是把包容分流误配为并行汇合容易出现的错误。
当分支之间还有循环、跳转或共享节点时，简化的“只等启动过的路”不足以说明全部行为。业务图可以先拆成清晰子流程，再由实施团队按目标引擎支持范围确认。如果一条规则写不清启动条件和退出条件，不必急着使用更复杂的网关符号。
画图时别把消息流和顺序流混用
同一流程的泳道可以分别代表采购、财务和仓库，活动之间仍用顺序流表示执行次序。泳道说明谁负责，网关说明如何分流和等待，两者解决的问题不同。需要先确定责任边界时，可配合泳道图的角色与交接方法使用。
不同参与者的池之间才通过消息流表达消息交互，不能把一根顺序流直接跨池连接。比如供应商是外部参与者，“发送采购单”与供应商“确认订单”之间应表达消息，而不是假设同一个执行标记穿过两个独立流程。BPMN的符号与语义定义可查阅OMG BPMN 2.0.2规范。
用四次走图找出重复执行和一直等待
先只画采购主路径，再按同一组任务做四次推演：
- 资料缺失：标记进入补充任务；财务和库存都不应提前开始。
- 财务先完成：标记停在汇合处；库存完成后，下游采购判断只执行一次。
- 库存先完成、财务不通过：两项结论都到达后转向退回调整；不能因先完成的库存结果而提前采购。
- 某项审查迟迟未完成：流程继续等待，并触发另行定义的提醒、超时处理或取消规则；“+”网关本身不会自动决定超时后的业务去向。
在墨刀画布上保留节点编号、条件和等待说明，再邀请财务与仓库各自走一条分支。分享时可以让评审者回答一个具体问题：“财务拒绝以后，库存这项任务怎么办？”如果图和规则无法给出一致答案，就回到对应分支修改，而不是只调整线条更整齐。
最终留下的应是一张能解释每次分流理由、每次汇合等待对象的流程图。之后若接入执行引擎，再补变量、任务配置、事件和错误处理；画布上的流程表达与可运行的流程定义，是前后相连但不同的工作。
