jeeflow 系列 · 第 1 篇（认识季）
后端群里几乎每周都有人问同一个问题："审批流用什么？"
回答也总是同一个：Flowable。
但很少有人追问后半句——选型完成之后，故事才刚开始：一个 jar 数 MB、依赖一大堆、表几十张的引擎，进到你的业务系统里，是"引入了一个能力"，还是"引入了一个麻烦"？
这篇不劝退 Flowable，也不吹自研。我们把账算清楚：Flowable / Activiti / Camunda 这些成熟引擎，到底贵在哪？什么场景下，一个 98KB 的轻量引擎反而是更理性的选择？
本系列由 mldong 快速开发框架生态延续而来，第 0 篇《从 mldong 到 jeeflow：一个工作流引擎的独立进化》讲了 jeeflow 的完整来龙去脉，欢迎先看那篇。
一、成熟引擎的代价，藏在哪里
Flowable、Activiti、Camunda 都是 BPMN 2.0 标准的优秀实现，功能强大毋庸置疑。但"强大"是有标价的，这笔账通常要在上线后慢慢还：
1. 引擎本身就不轻。 Flowable 引擎 jar 数 MB，加上流程定义解析、表单、历史等模块，跑起来的内存和启动时间都不是小数目。Camunda 如果是平台版，更是一整套东西。
2. 数据表几十张起步。 Flowable 光引擎表就有 70+ 张（ACT_ 前缀），Activiti 60 张上下，Camunda 也 30 张左右。你的数据库 schema 里瞬间多出一片"别人家的表"，迁移、备份、监控都要跟着适配。
3. 学习曲线不是"陡"，是"长"。 BPMN 2.0 本身就是一个完整的规范：泳道、子流程、事件、网关、边界事件……新同学入职先啃一个月 BPMN 文档，才能动手画第一个"请假流程"。
4. 深度集成是你的活。 用户体系要映射、权限要对接、事务要配合、前端流程设计器要集成。引擎是别人的，胶水代码是你的。
5. 升级是心理阴影。 大版本升级意味着 API 变动、表结构迁移、历史数据兼容——很多团队干脆"引擎版本永不升级"。
这些都不是 Flowable 的错——它只是为一个更宏大的目标（复杂 BPM 平台）而生的。问题在于：如果你的需求只是"业务系统里有一块审批能力"，用它就属于用火箭送外卖。
二、那什么时候才该自研？
先把结论放前面：自研不是省事，是换一种成本结构。
适合用成熟引擎的场景：
- 你要做的是流程平台本身（面向多租户、复杂编排、流程市场）
- 业务流程重度依赖 BPMN 高级特性（事件、网关、复杂补偿）
- 团队有专门的 BPM 工程师，养得起这个复杂度
适合轻量自研的场景（我们的判断）：
- 审批流是业务系统的一个模块，不是产品的全部
- 流程模式相对固定：发起、审批、退回、跳转、会签、抄送、委托
- 希望引擎与自家框架深度集成（事务、权限、用户体系、前端设计器）
- 希望引擎行为完全可控，出问题能快速定位
- 未来可能有多语言技术栈的业务团队接入（Java / Go / Python / Node）
自研的代价也要讲清楚：功能边界要自己守（不做复杂 BPM 就是不做）、测试体系要自己建、维护责任自己扛。自研引擎不是"免费"，是把成本从"学习别人的复杂度"转移到"维护自己的复杂度"。 只有当后者的复杂度显著低于前者时，才划算。
三、一张表看清选型
| 维度 | Flowable | Activiti | Camunda | jeeflow |
|---|---|---|---|---|
| 定位 | BPM 引擎 | BPM 引擎 | 流程平台 | 业务系统内嵌审批引擎 |
| 引擎体积 | 数 MB | 数 MB | 平台级 | 98KB |
| 数据表 | 70+ 张 | 60 张上下 | 30 张上下 | 8 张（5 核心 + 3 管理） |
| 流程标准 | BPMN 2.0 | BPMN 2.0 | BPMN 2.0 | LogicFlow JSON |
| 框架依赖 | 需集成 Spring 等 | 同左 | 平台绑定 | 零依赖（仅 slf4j-api，provided） |
| 学习曲线 | 陡（BPMN 规范） | 陡 | 陡 | 平（JSON + 节点/边） |
| 扩展方式 | Handler / Listener | 同左 | 平台扩展点 | SPI 体系（核心 6 + 扩展 5，任意环节可替换） |
| 语言覆盖 | Java 为主 | Java | Java | Java / Go / Python / Node 四语言 |
| 事务/权限集成 | 自己接 | 自己接 | 平台提供 | 引擎不感知，业务层事务模板包裹 |
注：表数量为各引擎常见版本的大致规模（Flowable 6.x 的 ACT_ 系列约 70 余张），供量级参考；精确数字以各引擎官方文档为准。jeeflow 数据对齐 v1.8.4（8 张表 = 5 核心 + 设计/历史/委托 3 管理）。
四、我们的选择：mldong 场景下的自研
mldong 快速开发框架（开源在 Gitee 的 Java 快速开发框架）里内置了一套自研工作流引擎，当初做这个决定时，就是照着上面的判断来的：
- 需求边界清晰：框架要的是"业务系统里的审批能力"，不是流程平台——发起、审批、退回、跳转、会签、抄送、委托，够用且好用；
- 流程定义用 LogicFlow JSON：节点 + 边 + 表达式，可视化设计器画完就是这份 JSON，没有 BPMN 的规范负担；
- 与框架深度集成：接口契约（code=0/msg、submitType 枚举）、用户体系、前端 vben5 流程设计器，全部对齐；
- Java 双主线（boot2 / boot3）的 wf 模块完全一致，前端开箱即用。
引擎在框架里跑得很好。但后来我们发现，这套能力值得独立出去——于是有了 jeeflow：一个 98KB、零框架依赖、DDD 设计、SPI 体系可插拔的工作流引擎 SDK，并演进出了 Java / Go / Python / Node 四语言同构的"多语言联邦"。这是第 0 篇讲过的故事。
五、结语：选型没有银弹，只有匹配
Flowable 很好，但它是为"复杂 BPM"生的。如果你的系统里只是需要"审批"，请先算清楚那几十张表、数 MB 依赖和 BPMN 学习成本，是不是你想要的。 轻量自研也不是银弹，它是把复杂度换了个位置——换来的是可控、可移植、可掌控。
下一篇预告：《jeeflow：98KB 的工作流引擎长什么样》——一个零依赖引擎的核心设计：DDD 聚合根、6 大 SPI、状态机、9 种流程模式，拆开给你看。
相关链接
- jeeflow 文档站：jeeflow-doc.mldong.com
- 引擎仓库（GitHub · mldong 组织）：
jeeflow-java/jeeflow-go/jeeflow-python/jeeflow-node/jeeflow-ui - 上游框架：mldong 快速开发框架（Gitee 开源）
