前言

流程工单是企业内部系统里非常常见的场景，比如：

请假审批。
报销审批。
合同审批。
采购审批。
订单售后工单。
客诉工单。

面试常问：

为什么不用 if else 写审批流程。
状态机和工作流有什么区别。
撤回、驳回、转派怎么设计。
并行审批怎么合流。
流程变更怎么兼容历史单据。

流程系统的核心问题

流程系统本质上要解决：

流程定义。
节点流转。
审批记录。
状态追踪。
异常处理和回退。

flowchart TD
    A[发起工单] --> B[审批节点1]
    B --> C[审批节点2]
    C --> D{是否通过}
    D -->|通过| E[结束]
    D -->|驳回| F[回到发起人]
    D -->|撤回| G[回到草稿]

为什么不能用 if else 堆流程

当流程只有两三个节点时，if else 看起来很直接。

但企业流程往往会变成：

不同部门不同审批链。
金额不同走不同流程。
紧急单和普通单规则不同。
合同类型不同审批角色不同。

如果全写死在代码里，会出现：

代码难维护。
规则改一次影响很多地方。
历史流程单据不好追踪。

工作流和状态机

状态机

状态机强调状态和状态之间的合法流转。

适合：

简单审批。
状态变化清晰的工单。

工作流引擎

工作流引擎强调流程定义、节点配置、角色、条件和流程图。

适合：

节点多。
规则复杂。
需要可视化配置。

对比：

方案	优点	缺点
状态机	简单、可控	复杂流程会膨胀
工作流引擎	灵活、可配置	学习和运维成本高

节点流转怎么设计

常见节点动作：

通过。
驳回。
撤回。
转派。
加签。
退回上一步。

每个动作都要有：

当前节点校验。
权限校验。
审批记录。
状态更新。

stateDiagram-v2
    [*] --> 草稿
    草稿 --> 审批中: 提交
    审批中 --> 已通过: 所有节点通过
    审批中 --> 已驳回: 任一节点驳回
    审批中 --> 已撤回: 发起人撤回

撤回怎么做

撤回通常有两个前提：

还没走到不可撤回节点。
业务规则允许撤回。

实现上要判断：

当前单据状态。
当前用户是否是发起人。
是否已经有后续节点处理。
是否有审批日志。

并行审批怎么做

并行审批常见于：

多部门会签。
财务和法务并行。
多角色同时审批。

关键点：

并行节点要全部通过才能汇总。
任一节点驳回时如何处理。
是否支持部分通过。

flowchart TD
    A[发起审批] --> B[财务审批]
    A --> C[法务审批]
    B --> D[汇总]
    C --> D
    D --> E{是否全部通过}
    E -->|是| F[继续下一节点]
    E -->|否| G[驳回或退回]

流程变更怎么兼容历史单据

企业里最头疼的问题之一是“流程改了，老单子怎么办”。

常见方案：

历史单据绑定创建时的流程版本。
新单据走新流程。
老单据按旧版本继续流转。
重要变更前先冻结旧模板。

面试回答：

流程定义通常要版本化。流程改动不能影响已经发起的单据，否则审批记录和责任边界会乱掉。

审批记录为什么要完整

审批系统不是只看最终结果，还要看过程：

谁发起。
谁审批。
什么时间审批。
审批意见是什么。
节点是否转派。

这些都关系到审计和合规。

常见高频题

为什么工单系统里经常要做状态机？

因为工单的状态流转是强约束的，状态机比散落的 if else 更可控。

撤回和驳回有什么区别？

撤回通常是发起人主动收回，驳回通常是审批人拒绝并返回到某个节点。

流程版本为什么重要？

因为历史单据必须按照创建时的规则继续流转，不能被新规则直接覆盖。

工作流引擎和自己写状态机怎么选？

流程复杂、规则多、需要可视化时用工作流引擎；流程简单、可控且性能要求高时用状态机。

加签和转派有什么区别？

加签是增加审批人，转派是把当前审批责任转给其他人。

总结

流程工单的回答主线：

简单流程可以用状态机，复杂流程考虑工作流引擎。
节点流转要支持通过、驳回、撤回、转派、加签。
流程定义要版本化，保证历史单据可追踪。
审批记录必须完整，满足审计和合规。
并行审批、条件分支和回退都要明确规则。

企业里的流程系统不是“画个流程图”，而是一个带版本、带审计、带权限、带回退的状态控制系统。