2. 工作流基础回顾：节点类型、节点生命周期与标准参数模型
在深入审查意见驱动的参数配置之前，必须统一团队对工作流基础概念的认知。本章从三个维度构建共识：节点类型（流程的“积木”）、节点生命周期（每个积木的“状态机”）以及标准参数模型（积木间的“通信协议”）。
2.1 核心节点类型
BPMN 2.0 规范定义了数十种节点，但在审批工作流中，90% 的场景由以下三类节点覆盖：
| 节点类型 | BPMN 元素 | 核心职责 | 典型场景 |
|---|---|---|---|
| 用户任务 | User Task | 等待人工操作，产生审查意见 | 部门审批、会签、知会 |
| 服务任务 | Service Task | 自动执行逻辑，无人工干预 | 发送邮件、调用接口、数据转换 |
| 网关 | Gateway | 控制流程路由，决定走向 | 条件分支、并行、合并 |
实践提示： 在 Camunda 中，用户任务通过
camunda:formData 或外部表单收集意见；服务任务通过 camunda:class 或 camunda:delegateExpression 绑定 Java 委托；网关通过条件表达式（如 ${approved == true}）驱动分支。
2.1.1 网关子类型详解
网关是路由决策的核心，不同子类型对应不同的语义：
- 排他网关 (Exclusive Gateway)：多选一，默认走第一条满足条件的路径。适合“同意/驳回/转审”等互斥分支。
- 并行网关 (Parallel Gateway)：分叉时激活所有后续路径，合并时等待所有到达路径。适合“会签”或“并行任务”。
- 包容网关 (Inclusive Gateway)：分叉时激活所有满足条件的路径，合并时等待所有被激活的路径。适合“条件并行”。
- 事件网关 (Event Gateway)：基于捕获事件（如定时器、消息）决定分支，较少用于审批流。
常见误区： 排他网关与包容网关的区别在于“是否允许同时走多条路径”。排他网关是互斥的，包容网关是条件并行的。在审批流中，若需要“部门经理审批通过后，同时通知财务和法务”，应使用并行网关，而非排他网关。
2.2 节点生命周期
每个节点实例（Process Instance 中的 Activity Instance）都遵循一个标准状态机。理解生命周期是配置“审查意见驱动参数”的前提——因为参数只能在特定状态被读取或写入。
节点生命周期中的关键状态转换点：
- 待处理 → 运行中：引擎根据序列流条件激活节点。此时可读取流程变量，但尚未执行节点逻辑。
- 运行中 → 已完成：用户任务提交表单/服务任务执行完毕。此时可写入审查意见或输出参数。
- 运行中 → 异常/重试：服务任务抛出异常或用户任务超时。此时可触发补偿或重试策略。
- 任意状态 → 已取消：流程被终止或节点被跳过。此时应清理临时变量。
2.3 标准参数模型
工作流引擎通过流程变量 (Process Variables) 在节点间传递数据。标准参数模型定义了变量的作用域、类型和生命周期，是“审查意见驱动配置”的数据基础。
2.3.1 参数作用域
| 作用域 | 可见范围 | 生命周期 | 典型用途 |
|---|---|---|---|
| 全局变量 | 整个流程实例 | 流程实例创建 → 结束 | 申请人、金额、审批结果 |
| 局部变量 | 当前节点及子流程 | 节点激活 → 完成 | 节点输入表单、临时计算结果 |
| 任务变量 | 仅当前用户任务 | 任务创建 → 完成 | 审查意见、附件列表 |
2.3.2 标准参数类型与命名规范
为避免参数混乱，建议团队遵循以下命名约定：
- 输入参数：前缀
in_，如in_approverList、in_amount。 - 输出参数：前缀
out_，如out_opinion、out_approved。 - 配置参数：前缀
cfg_，如cfg_timeout、cfg_skipCondition。 - 临时变量：前缀
tmp_，如tmp_calculatedScore。
最佳实践： 在 Camunda 中，使用
execution.setVariable("out_opinion", "同意") 写入输出参数；在 Activiti 中，通过 delegateExecution.setVariableLocal("tmp_result", value) 设置局部变量。始终明确作用域，避免全局变量污染。
2.3.3 参数模型与节点类型的映射
不同节点类型对参数模型的依赖程度不同：
2.4 本章小结
工作流基础回顾的核心要点：
- 节点类型：用户任务（人工）、服务任务（自动）、网关（路由）是审批流的三大基石。
- 节点生命周期：待处理 → 运行中 → 已完成/异常/取消，每个状态转换都是参数读写的时机。
- 标准参数模型：全局/局部/任务三级作用域，配合
in_/out_/cfg_/tmp_命名规范，确保参数可追溯、可维护。