Activiti 工作流入门
1. 一句话简介
Activiti 是业界最流行的开源 BPMN 2.0 工作流/流程引擎，通过定义「业务流程」并以标准 XML（BPMN 2.0）描述流程图中各审批节点与流转顺序，再交给 ProcessEngine（进程引擎）统一管理流程的部署、启动与执行。核心解决的是「如何把原本散落在业务代码里的审批流转逻辑——谁是下一节点、谁能认领、按什么顺序流转——抽取成可编排、可跟踪、可持久化的流程模型」。模块 demo-activiti 使用 activiti-spring-boot-starter（7.1.0.M2）接入，启动时自动在 MySQL 中创建约 28 张 ACT_* 表（如 ACT_RE_* 流程定义、ACT_RU_* 运行时、ACT_HI_* 历史），并演示了一个「开始 → first 用户任务 → second 用户任务 → 结束」的审批链。
2. 什么时候使用
✅ 适用场景
- 业务中存在固定、多节点、需人工参与的审批流转：典型的如请假、报销、合同、发文等审批链。Activiti 用
userTask+candidateGroups把每个审批节点建模为「由某个用户组可认领的任务」，节点流转通过sequenceFlow明确定义，比在代码里手写一长串if/else状态机清晰得多。 - 流程定义要独立于业务代码、可随时调整：流程用 BPMN 文件描述（demo 里部署
team01.bpmn，可配套 Yaoqiang 等图形化建模工具绘制），改流程时无需改动 Java 代码，只需重新部署流程定义；流程版本管理也由 Activiti 内置。 - 需要完整的流程运行时与历史追踪：demo 配置了
history-level: full+db-history-used: true，Activiti 会把流程实例、任务、变量变更等全量历史写入ACT_HI_*表，便于审计、回溯、统计「某单走到哪一步、谁处理过」。 - 需要与 Spring 生态深度集成：Activiti 提供官方
spring-boot-starter，AutoConfiguration 自动装配ProcessRuntime、引擎 Service（Runtime / Task / History），配合 Spring Boot 开箱即用。
❌ 不适用 / 需谨慎
- 流程极简、仅单层审批或可硬编码：只有几步固定判断、且几乎不会变，用普通状态机或代码分支即可，引入工作流引擎明显过重。
- 只想要一个轻量级状态机 / 简单的工单流转：Activiti 带来的是完整 BPMN 引擎语义与大量
ACT_*表，对简单场景属于过度设计。 - 流程由开发者手写 XML 维护、图形建模与配置成本高：Activiti 的建表、BPMN 定义、模型管理都需要一定学习曲线；demo（
application.yml）中nullCatalogMeansCurrent: true必须显式配置，否则 MySQL 8.x 下自动建表会因扫描全部数据库而失败——这类坑需要了解才能规避。 - 追求零数据库依赖、纯内存快速原型：Activiti 依赖 MySQL 等数据库持久化流程数据，无法脱离 DB 运行。
- 需要开箱即用的可视化流程设计器 / 流程审批中心：引擎本身不带成熟的前端流程设计器与审批界面，需自行集成（如 Activiti 的 Modeler 或自建 UI），前端工作量需要评估。
3. 常见业务场景
审批类工作流（办公自动化 OA）：请假、报销、差旅、用印等审批单提交后，按部门、金额、职级配置的节点逐级流转。demo 的 team01.bpmn 正是这种模型的雏形——开始事件进入 first 用户任务，再流转到 second 用户任务，最后结束事件；真实系统中把这两个 userTask 替换为「直属主管审批」「部门经理审批」，并给每个节点配 candidateGroups，即可让对应组的用户认领办理。
按用户组分配与认领任务：demo 里两个 userTask 都配置了 activiti:candidateGroups="activitiTeam"，配合 SecurityConfiguration 中注册的 GROUP_activitiTeam 用户组，实现「组内成员都可看、谁先认领谁处理」的抢单/认领机制，适用于任务回退、多人协作、分单处理场景。
流程全生命周期历史审计：demo 开启 history-level: full，Activiti 完整记录每个流程实例从启动到结束的执行轨迹、任务处理人和变量变化。对应合规与审计需求——财务、采购、药品等监管严格的业务，需要事后追溯「谁在何时做了哪步操作」。
以认证身份驱动流程操作：demo 的 SecurityUtil.logInAs("salaboy") 演示了在测试/API 中模拟指定用户身份、再通过 securityUtil 切换当前用户身份执行流程操作，并借助 org.activiti.engine.impl.identity.Authentication.setAuthenticatedUserId 让引擎感知「当前操作用户是谁」。真实场景中即对应「提交人是谁、当前审批人是谁」的身份透传，支撑任务待办、催办、转办等对「操作人」敏感的流程功能。
4. 同类技术对比
| 技术方案 | 标准与建模 | 与 Spring 集成 | 分布式/高并发 | 学习成本 | 适用规模 | 备注 |
|---|---|---|---|---|---|---|
| Activiti（本模块） | BPMN 2.0，原生引擎级支持 | 强，官方 starter 自动装配 | 中，可集群但需自行扩展 | 中高（BPMN XML、引擎概念多） | 中大型、流程中心化单体 | 生态活跃，历史记录完整 |
| Flowable | BPMN 2.0（由 Activiti 5/6 社区 fork 演进而来） | 强 | 中高，同样可集群 | 中高，与 Activiti 接近 | 中大型 | 功能与定位相似，社区更活跃、维护更积极 |
| Camunda | BPMN 2.0 + CMMN/DMN | 强 | 高，组件化、运行时可测试性设计佳 | 中高，但文档/工具链完善 | 中大型 | 自带 Workflow Engine + AAA 全套，运维平台成熟 |
| 自研状态机 / 硬编码审批 | 无标准，业务代码内实现 | — | 取决于实现 | 低 | 小型、简单需求 | 改动成本高、可维护性差，无历史审计体系 |
选型建议
- 简单固定审批、快速落地、没有专门流程团队：直接用自研状态机或代码分支即可，避免引入引擎带来的 BPMN 与数据库复杂度。
- 团队熟悉 Java + Spring Boot、需要一个能深度嵌入进程内、部署轻的开源 BPMN 引擎：选 Activiti 或 Flowable。Activiti 老牌、库大、资料多；Flowable 由原 Activiti 团队 fork，社区更活跃、维护更积极，若重新立项可优先考虑。
- 需要成熟的「建建模、办流程、管监控」一体化平台，且愿意接受较重组件：选 Camunda，其自带 Workflow Engine 与完备的建模/运维体系，运行时可测试（Run & Test）能力强，适合企业级流程中台。
- 看重流程可视化、决策（DMN）与人工任务管理成套产出：同样优先 Camunda；若预算与团队有限，Flowable 也有较完整的 Modeler 生态可作替代。