1. 审批流基础：什么是审批流、核心要素与常见场景

大家好，我是老赵。今天咱们开始聊审批流优化这个话题。

先问个问题：你每天打开办公系统，是不是总能看到几个待审批的红点？请假、报销、合同、采购……这些背后跑的都是审批流。说白了，审批流就是一套自动化的决策路径——把“谁同意、谁拒绝、下一步去哪”这些规则，用代码固化下来。

我刚开始做后端那会儿，觉得审批流不就是if-else嘛。后来被一个复杂的合同审批流程坑过——节点跳转逻辑写死了，业务一变就得改代码，改一次上线一次，运维差点把我拉黑。嗯，从那以后我才认真琢磨：审批流到底该怎么设计，才能既灵活又高效。

1.1 什么是审批流

审批流，全称是“审批工作流”。它模拟现实中的审批过程：一份单据（比如请假申请）从发起人出发，经过各级审批人，最终到达结束状态。整个过程由系统自动路由，不需要人工传递纸质单子。

你想想看，如果没有审批流，会是什么场景？

• 员工打印请假单 → 找组长签字 → 找经理签字 → 找HR备案
• 中间任何一个人不在工位，流程就卡住
• 纸质单子容易丢，事后查记录全靠翻柜子

有了审批流系统，这些全变成线上操作：提交、通知、审批、归档，一气呵成。我在上一家公司接手过一个老系统，审批流还是用状态机硬编码的，每次加一个审批层级都要改核心代码。后来重构时，我们把流程定义抽成了配置化，才算是真正解脱了。

1.2 核心三要素：节点、路由、状态

审批流再复杂，拆开来看就三个东西：节点、路由、状态。我习惯把这叫“审批流三件套”。

1.2.1 节点（Node）

节点就是审批流里的“停靠站”。每个节点代表一个处理动作。常见的节点类型有：

1.2.2 路由（Route）

路由决定了“审批完这个节点，下一步去哪”。路由规则通常写在节点之间的连线上。常见的路由模式有：

• 顺序路由：A → B → C，一条线走到底
• 条件路由：根据表单字段值，走不同分支
• 并行路由：同时发给多个审批人，各自独立审批
• 回退路由：驳回后回到上一个节点或发起人

这里有个坑，我踩过不止一次——路由条件不要写死成代码。比如“金额大于5000走总监审批”，如果这个阈值写在Java代码里，业务想改成8000就得发版。更好的做法是把路由条件做成表达式配置，存在数据库里，运行时动态解析。

1.2.3 状态（Status）

状态描述的是“当前流程走到哪了”。每个节点都有对应的状态值。一个典型的审批流状态变迁如下：

草稿 → 审批中 → 审批通过 / 审批驳回
                ↓
            已撤回 / 已作废

状态设计时，我建议用整数枚举而不是字符串。为什么？因为整数比较快，而且不容易出现“Approved”和“approved”这种大小写不一致的坑。我在数据库里一般这样存：

1.3 常见业务场景

审批流几乎无处不在。我整理了几个最常见的场景，你看看是不是都遇到过：

1.3.1 人事类：请假、加班、出差

这类流程的特点是层级固定：员工 → 组长 → 经理 → HR。天数不同可能跳级，比如3天以内组长批，3天以上经理批。路由条件通常跟“请假天数”挂钩。

1.3.2 财务类：报销、借款、付款

财务流程的核心是金额阈值。我见过一个公司的报销流程：500元以下直接财务批，500-5000元部门经理批，5000元以上总经理批。金额越大，审批层级越多。这类场景对数据一致性要求极高，不能出现“钱付了但流程没走完”的情况。

1.3.3 采购类：采购申请、合同审批

采购流程往往涉及多部门会签：采购部、法务部、财务部、总经理。每个部门都要审一遍，而且顺序不能乱。这种场景下，并行路由和会签节点用得最多。

1.3.4 行政类：用印、资产领用

这类流程相对简单，通常是单线顺序：申请人 → 部门负责人 → 行政。但要注意回退逻辑——比如用印申请被驳回后，修改完能不能重新提交？还是必须重新发起？这个细节很容易被忽略。

1.4 一张图看懂审批流核心结构

下面这张SVG图，把审批流的三个核心要素和它们之间的关系画出来了。你可以把它当作本章的“知识地图”。

1.5 本章小结

这一章我们聊了审批流的基础。说白了，审批流就是把现实中的审批规则搬到线上，用节点、路由、状态三个要素来建模。不管多复杂的流程，拆开来看都是这三样东西的组合。

我个人的习惯是：拿到一个审批需求，先画节点图，再标路由规则，最后定义状态表。三步走完，流程的骨架就清晰了。后面再考虑数据怎么存、查询怎么优化——这些咱们后面的章节会慢慢展开。