Activiti 和 Flowable 的工作战争已经打了十年。我见过太多团队把这两个框架折腾得死去活来，流引最后发现真正的擎框问题从来不在引擎本身。

去年帮一家物流公司做技术咨询，工作他们的流引仓储系统用着 Activiti 5.2，跑了两百万个流程实例。擎框每次大促前都得停服扩容，工作数据库里躺着三百多张历史表。流引负责这块的擎框架构师头发快掉光了，他说“换引擎等于重新投胎”。工作后来我们只做了一个改动——把流程定义里的流引服务任务全部改成异步，配合 MQ 削峰。擎框双十一当天，工作引擎负载降了百分之六十。流引你看，擎框问题从来不是引擎不够强，而是你用错了姿势。

选型这事，说穿了就三条线。第一条看你的流程是长事务还是短事务。审批流、工单流这种短事务，用 Flowable 的并行网关加表达式路由就够了。但要是碰上银行信贷审批那种跑半个月的长流程，你得考虑状态持久化策略。Flowable 的历史表能给你完整审计轨迹，Activiti 7 在这方面反而砍了不少。

第二条线看团队底子。别迷信什么“微服务原生支持”，Activiti 7 那套 Spring Cloud 集成说实话有点重。如果你团队就五六个人，我劝你直接用 Flowable 6.x 的 REST API，配个 Postgres 就完事。我见过一个创业公司，四个人用 Camunda 8 的 Zeebe，结果光学那个云原生架构就花了俩月，业务早凉了。

第三条线最容易被忽略——流程可视化。别听厂商吹“低代码拖拽”，真正跑起来你就知道，业务部门要的流程图和开发要的 BPMN 模型永远是两码事。我做过一个医疗设备报修系统，业务方坚持要用泳道图表达跨部门协作，最后我们拿 Flowable 的 Modeler 二次封装，把节点类型限定成五种，反而用得挺顺。

说点扎心的。框架选型这件事，百分之八十的坑都出在“过度设计”。有个做供应链的朋友，非要用状态机引擎自己撸一套流程系统，结果每次需求变更都得改代码。后来换了 Flowable，把路由规则全部外置到数据库，业务方自己就能调流程。他跟我说，这才叫“把复杂性关进笼子里”。

至于性能调优，别一上来就调线程池。先看你的流程实例生命周期——大部分系统里，百分之九十的流程都是短命的，走完就完事。这时候你该关注的是历史数据归档策略。Flowable 有个 job 表，默认每秒钟扫描一次，你要是流程量大，把异步执行器的核心线程数调到 20，队列容量设 1000，基本能扛住日百万级。真要再往上冲，分库分表是唯一出路，别指望引擎层面能给你什么银弹。

最后聊个反直觉的观察。很多团队把流程引擎当数据库用，往扩展字段里塞各种业务数据。这毛病我见一次骂一次。引擎的本质是协调器，不是存储层。你非要把订单状态塞进去，等流程跑完想查历史，那查询性能绝对让你哭。规矩很简单——流程引擎只管“下一步该谁做”，业务数据放你自己的库里，两边通过流程实例 ID 关联。这招比什么高级配置都管用。

说到底，Java 工作流引擎这行当，成熟得不能再成熟了。Flowable、Activiti、Camunda 三兄弟功能上九成相似，选谁都差不多。真正拉开差距的，是你能不能克制住“用引擎解决一切”的冲动。流程建模别贪多，节点类型够用就行；部署方式别整花活，单体应用里嵌个引擎照样跑得欢。记住，工具是拿来用的，不是拿来供的。