3. 审查与审批流程概述
在工程化工作流中，“审查”与“审批”是两个极易混淆但本质不同的环节。理解它们的区别，是设计参数传递路径的前提。本章从概念对比出发，梳理典型审批模式，并引出参数传递的核心需求。
3.1 审查与审批的区别
审查（Review）侧重技术正确性与质量评估，参与者通常是同级或技术负责人，输出意见但不一定具备终止权。审批（Approval）侧重决策授权与资源释放，参与者通常是管理者或合规角色，输出具有约束力的通过/驳回结果。
| 维度 | 审查（Review） | 审批（Approval） |
|---|---|---|
| 核心目标 | 发现缺陷、提升质量 | 授权放行、控制风险 |
| 参与者 | 技术专家、同级同事 | 管理者、合规官、安全负责人 |
| 输出结果 | 意见列表、修改建议 | 通过 / 驳回 / 条件通过 |
| 是否可跳过 | 通常可基于风险跳过 | 通常不可跳过（硬性门禁） |
| 参数传递特点 | 传递上下文、评论、附件 | 传递决策结果、签名、时间戳 |
工程实践提示： 在参数传递设计时，审查环节应保留“意见聚合”能力（如汇总多条评论），而审批环节应保留“决策链”能力（如记录谁在什么时间做了什么决定）。
3.2 典型审批流程
根据参与人数与决策逻辑，审批流程可归纳为三种基本模式：单人审批、会签、或签。每种模式对参数传递的要求不同。
3.2.1 单人审批（Single Approval）
流程中只有一个审批节点，任意一位指定审批人即可完成决策。参数传递路径简单：发起人 → 审批人 → 结果回传。
3.2.2 会签（Counter-sign / Unanimous Approval）
需要所有指定审批人全部通过，流程才能继续。参数传递需要聚合所有审批人的意见，并在最后一人通过时触发状态变更。
3.2.3 或签（Any Approval / Parallel Approval）
多位审批人中，只要有一人通过即视为整体通过。参数传递需要快速判断第一个通过的决策，并终止其他待办。
| 模式 | 决策逻辑 | 参数传递关键点 | 典型场景 |
|---|---|---|---|
| 单人审批 | 1人通过 = 通过 | 单一路径，无聚合需求 | 直属上级审批 |
| 会签 | 全部通过 = 通过 | 需聚合所有意见，记录完整投票 | 跨部门联合审批 |
| 或签 | 任意1人通过 = 通过 | 需快速终止，避免重复处理 | 紧急变更、值班审批 |
参数传递陷阱： 会签模式下，如果参数传递设计为“覆盖式”（后一个意见覆盖前一个），将导致前序审批意见丢失。正确做法是使用“追加式”数据结构（如数组或列表）存储每个审批人的决策。
3.3 流程中的参数传递需求
无论采用哪种审批模式，工作流引擎都需要在节点间传递一组核心参数。这些参数可分为三类：
- 上下文参数： 流程实例ID、发起人、发起时间、业务主键、关联单据。
- 决策参数： 审批结果（通过/驳回/转办）、审批意见、审批人、审批时间、签名信息。
- 控制参数： 当前节点名称、待办人列表、超时策略、跳转条件。
下图展示了单人审批模式下，参数在节点间的典型传递路径：
3.4 参数传递的工程挑战
在实际工作流引擎中，参数传递面临三个核心挑战：
- 参数一致性： 分布式环境下，多个审批节点可能并发操作同一参数，需保证最终一致性。
- 参数版本管理： 审批过程中参数可能被多次修改，需保留历史版本以便追溯。
- 参数安全： 敏感信息（如签名、金额）在传递过程中需加密，防止中间节点泄露。
常见错误： 将审批意见直接覆盖到流程实例的全局变量中，导致会签模式下前序意见丢失。正确做法是使用“意见列表”结构，每次追加新意见。
下图展示了会签模式下参数聚合的典型结构：
3.5 参数传递设计原则
基于上述分析，在审查与审批工作流中设计参数传递时，应遵循以下原则：
- 显式传递： 每个节点明确声明需要哪些输入参数、输出哪些参数，避免隐式依赖全局变量。
- 不可变性： 上游参数在传递过程中不应被下游节点修改，如需修改应创建副本。
- 可追溯性： 每个参数变更都应记录操作人、操作时间、变更前后值。
- 最小化原则： 只传递当前节点需要的参数，避免传递整个流程上下文造成性能浪费。
推荐实践： 使用“参数契约”定义每个节点的输入输出规范，并在流程启动时进行校验。这可以提前发现参数缺失或类型不匹配的问题，避免运行时错误。