双人审批流程概述：审批节点、角色与状态流转
聊到双人审批，你想想看，很多开发者第一反应就是：“不就是两个人都点同意嘛，有什么好讲的？”
说实话，我刚开始也是这么想的。直到有一次做支付SDK的接入改造，沟通了、测试了、联调了，结果上线第一天就出了大问题——审批单被一个人提交就自动流转到下一个环节了。嗯，从那以后我才知道，双人审批的流程设计，远不止“两个人点通过”那么简单。
审批节点：流程里的关键动作站
审批节点，说白了就是流程中的“关卡”。每一个节点代表一个需要执行的动作。我个人习惯在流程图里把它叫做“动作站”，更形象。
在双人审批流程里，节点通常分成三类：
- 发起节点：申请者提交审批的地方。这个节点通常不需要人工干预，一切由系统自动触发。
- 审批节点：核心环节。两位审批人先后在同一节点上做出决定。实际项目中，这些节点可能还会被细分成“会签节点”和“或签节点”。
- 完成节点：流程的终点。条件满足后，系统自动归档或者触发后续业务动作，比如接口SDK的权限下发。
别看只有三类，节点之间的串联方式千差万别。我之前在项目里见过一种奇葩设计：同一个审批环节居然拆成了两个独立节点，结果第一位审批人点完，第二位根本不知道这个单子是干嘛的。流程跑不通，问题出在哪？节点设计不清晰。
核心要点：节点本质上就是“谁在什么时机做什么事”。设计时一定要把“做什么事”明确下来。
角色：谁在流程里做什么
双人审批不是只有“申请人”和“审批人”那么简单。我总结了一下，实际项目里至少会涉及这四种角色：
| 角色 | 职责 | 我见过的坑 |
|---|---|---|
| 发起人 | 提交审批单，提供必要信息 | 发起时没做数据校验，后端报错 |
| 审批人 A | 第一道审核，通常是技术负责人 | 把节点和角色搞混，以为A必须在前 |
| 审批人 B | 第二道审核，通常是业务负责人或安全官 | 同一个人同时拥有A/B角色，形成自审 |
| 管理员 | 处理超时、撤回等异常场景 | 忘了给管理员加流转权限，流程卡死 |
这里我想特别强调一点：审批人A和B不一定是分先后的。很多团队会默认“A先审，B再审”，但实际场景里，两个人可以同时审。我曾经在一个OA系统改造里做过方案，两个人必须都看完才能通过，但谁先看谁后看不重要——这不叫串行，这叫并行会签。
注意：如果业务要求“A和B同一个人不能批”，你必须在角色分配时加校验。否则一张单子被同一个人用两个角色签了，双人审批就变成了单人假装双人。
状态流转：流程的骨架脉络
整个审批流程的流转，说白了就是状态机。每个审批单从诞生到消亡，经历多个状态。我习惯用一个公式来概括：
状态 + 事件 = 新状态
在双人审批里，常见的状态有这些：
- 草稿：发起人填了一半，还没提交。
- 待审：已提交，等待第一位审批人处理。
- 审中：第一位已处理，等待第二位（或双方同时处理）。
- 通过：两位审批人都同意，流程结束。
- 驳回：有一方拒绝，流程结束。
- 撤回：发起人在待审阶段主动取消。
- 超时：超过限定时间无人处理。
你看，这里面最容易被忽略的是“审中”状态。为什么会有这个状态？因为在双人审批里，“一位通过、另一位未处理”是一个合法的中间态。你不能让单子一直处于“待审”，也不能直接跳到“通过”。你想想看，如果只画两个状态“待审”和“通过”，中间那段半通过的时间段就成黑盒了，出问题你都追查不了。
实践经验：我在做双人审批的状态机时，每次都会在“审中”状态上加一个超时兜底。比如48小时内第二位没处理，自动升级给管理员。否则流程卡死是很常见的线上事故。
流程的可视化：一张图说清楚
文字讲再多，不如一张SVG图来的直观。下面这张图就是双人审批流程的典型骨架。我建议你在实际编码前，先在纸上照着这个思路画一画，把节点、角色、状态全串起来。
我每次评审设计方案的时候，第一件事就是让大家对着这种流程图过一遍。只要能说清楚“谁在哪个节点做什么，状态怎么变”，基本就能避免80%的流转bug。
总结一下关键点
- 双人审批的核心不在于“两个人”，而在于“两个独立决策”。节点、角色、状态三者必须对等映射。
- 状态流转里，审中是最容易被遗忘的中间态。千万别跳过它。
- 角色设计要避免“自审”和“角色绑定顺序”。A和B可以并行也可以串行，取决于业务。
- 异常处理（撤回、超时、驳回）必须在设计阶段就埋进去，别等上线再补丁。
嗯，说实话，双人审批的流程设计，说难不难，但细节特别多。我个人每次做这类方案，一定会先拉着团队把这张流程图过一遍，所有人确认无误，再开始写代码。流程通了，代码自然就顺畅了。