简介一套基于Spring Boot 2.6.13、MySQL 8和Flowable 6.8.1的完整工程项目面向需要快速搭建工作流平台的Java后端开发者解决BPM流程引擎与业务系统集成时的环境配置难题。压缩包共29个文件包括java源码、class编译文件、xml配置、yml环境配置、pom及properties文件并附带MySQL 8官方安装程序总大小382.9MB目录结构完整适合导入IDE直接构建。目前已有108人学习下载适合在本地快速搭建演示环境也可作为二次开发的起点。项目自带MySQL安装程序免去单独安装数据库的繁琐步骤同时包含Flowable流程设计的核心代码和配置文件开发者可快速理解Spring Boot如何整合Flowable并基于BPMN 2.0进行流程定义、任务管理和表单管理。读者还能参考项目中的RESTful接口设计与ORM交互方式降低工作流功能落地的门槛。1. 拿Flowable 6.8.1做审批流Spring Boot 2.6.13整合工作流为什么我建议直接抄这套配置做后台管理系统但凡业务里带审批两个字——请假、报销、合同会签、采购验收——迟早要碰工作流引擎。Flowable是目前国内中小团队用得最多的开源工作流方案之一但它的坑也最集中版本兼容、表结构初始化、流程部署方式、历史数据保留策略任何一个环节没对齐启动就直接报错。我拆过不少号称开箱即用的整合包真正能拿下来一条审批流程从头跑到结束的这套Spring Boot 2.6.13 MySQL 8.0 Flowable 6.8.1的组合算是比较省心的尤其它还自带了MySQL 8安装程序省掉了测试环境数据库版本不一致导致的脏数据问题。这篇笔记适合两类人一是刚接手Spring Boot项目、需要在三天内把工作流引擎跑起来并画出第一条请假流程的开发者二是已经在用Activiti或老版本Flowable想迁移到6.x并踩过版本兼容坑的熟手。文章会从版本选型讲到BPMN建模、引擎配置、任务审批接口最后收在验证和二次开发习惯上全程按可复现的标准写命令和代码直接抄。2. 为什么是Flowable 6.8.1版本兼容边界和引擎选型逻辑2.1 Spring Boot 2.6.x和Flowable 6.8.1的兼容性边界Flowable的版本和Spring Boot版本不是一一对应的官方虽然提供了starter但底层对Spring Boot版本的适配程度是分层的。Flowable 6.8.1这个版本在设计上对应的Spring Boot版本是2.6.x和2.7.x它用到了Spring Framework 5.3.x的特性对Spring Boot 3.x的Jakarta命名空间完全不兼容。所以如果你的项目基建已经升级到Spring Boot 3就不要在这个整合包上硬套需要另外找Flowable 7.x的方案。这里有一个容易被忽略的细节Flowable 6.8.1的flowable-spring-boot-starter会传递依赖Spring Boot的spring-boot-autoconfigure如果项目里同时存在其他starter版本仲裁可能导致Spring Boot被降级或升级。我在一个老项目里遇到过flowable-spring-boot-starter把Spring Boot从2.7.5拉到2.6.2的情况原因就是父POM里没有锁定Spring Boot版本号。解决方法是在pom.xml的dependencyManagement里显式声明spring-boot-dependencies版本用2.6.13让Maven的依赖仲裁以父POM为准。不要小看这个版本锁定问题。工作流引擎启动时要做的事情非常多——检查数据库连接、创建ACT_开头的表、初始化引擎配置、扫描并部署classpath下的BPMN文件——任何一个底层依赖的类加载异常都会在ProcessEngine创建阶段以ExceptionInInitializerError的形式暴露出来而且错误日志往往指向一些非常底层的库比如mybatis或ibatis的类不看依赖树根本定位不到根因。2.2 Starter包和ProcessEngine独立构建的差别整合Flowable有两种主流方式第一种是直接用官方starter第二种是只引入flowable-engine核心包自己创建ProcessEngine。官方starter的方式是引入flowable-spring-boot-starter-process后Spring容器会自动创建ProcessEngine、RepositoryService、RuntimeService、TaskService等Bean并且自动处理事务和懒加载。这种方式对大多数业务系统够用缺点是自动配置的过程像一个黑匣子——你不知道哪些Bean被创建了、哪些配置被覆盖了。自己构建ProcessEngine的方式更可控但代码量多还要自己管理事务边界和Spring的整合。我的建议是如果项目是从零开始直接走官方starter把自动配置的优先级搞清楚踩坑概率更低如果项目里已经有一个Flowable引擎在跑要整合到新的Spring Boot应用里才考虑手动构建因为这时候你可能需要同时维护两套数据源或两套引擎配置。这套资源在基石设计上走的是starter路线但它把MySQL 8安装程序也打包进来了这就意味着引擎的初始化环境是固定的标准MySQL 8而不是你来路不明的旧版本MySQL 5.7。在Flowable 6.x里MySQL 5.7和8.0的表结构初始化有一点差异尤其是ACT_RU_JOB表对时间字段的处理和索引长度限制5.7默认的utf8mb4配置可能导致索引长度超限Specified key was too long在8.0里则没有这个问题。所以这个资源自带MySQL 8安装程序等于提前把一个常见的环境坑给填了。2.3 Flowable每个核心Service在项目里的真实分工Flowable跑起来以后Spring容器里有五个最常见的Service新手容易弄混RepositoryService管流程定义的部署和查询就是你画的BPMN文件存到了哪里RuntimeService管流程实例的启动、删除、触发相当于流程的运行时指挥中心TaskService管待办任务——查询、认领、完成、转办HistoryService管历史数据包括已完成的流程实例、历史任务、活动记录IdentityService管用户和组但大多数情况下咱们不会真的往Flowable里同步用户都是业务系统自己管理用户代码里通过TaskService.setAssignee()来指定处理人。我在实际项目里的分工是流程部署和版本管理走RepositoryService和act_rep_procdef表待办列表查询永远走TaskService.createTaskQuery()这比直接查ACT_RU_TASK表安全得多因为Flowable的查询API会自己处理数据权限和变量条件历史归档走HistoryService但只保留业务需要的数据不要把引擎自带的全量历史数据都堆在线上库里。3. Spring Boot整合Flowable配置项逐项拆解和引擎初始化落地3.1 核心依赖和MySQL 8安装环境先把pom.xml的依赖写全需要注意的地方我会在代码块后面说明。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.6.13/version relativePath/ /parent properties java.version1.8/java.version flowable.version6.8.1/flowable.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version scoperuntime/scope /dependency dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter-process/artifactId version${flowable.version}/version /dependency dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter-rest/artifactId version${flowable.version}/version /dependency /dependenciesflowable-spring-boot-starter-process是这个整合包最核心的依赖它负责引擎的自动配置和Spring事务集成。flowable-spring-boot-starter-rest是可选的但如果你的前端需要通过REST接口直接操作系统里的流程数据——比如流程定义列表、模型列表——这个依赖可以把Flowable自带的REST API暴露出来。注意这个REST API默认的访问路径是/process-api而且它是没有做权限控制的生产环境一定要加Spring Security过滤掉这个路径或者直接不引入这个starter。MySQL Connector的版本这里用的是mysql-connector-jMySQL官方在8.0.31之后把mysql-connector-java重命名成了mysql-connector-jgroupId也要改成com.mysql。如果沿用老的mysql-connector-java写法在Maven中央仓库虽然还能拉到但会遇到Public Key Retrieval is not allowed的经典报错后面避坑章节我会具体展开。资源里自带的MySQL 8安装程序建议在Windows测试机上直接以默认配置安装到位。安装完成后记得在服务里确认MySQL服务是自动启动状态并且把root用户的密码设置成好记的固定值因为在下面的数据源配置里会用到。3.2 application.yml里Flowable相关的参数逐个说明server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/flowable?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 flowable: database-schema-update: true db-history-used: true history-level: audit async-executor-activate: true check-process-definitions: true deployment-mode: default process-definition-location-prefix: classpath:/processes/ process-definition-location-suffixes: - .bpmn20.xml - .bpmndatabase-schema-update: true的意思是允许Flowable在启动时自动建表或升级表结构。这个值在生产环境建议改成false由DBA统一管理数据库变更但在开发测试阶段保持true是最省心的——你换了新版本的Flowable引擎或者增加了一张业务表重启应用后引擎会自动补齐缺失的表。db-history-used: true决定是否启用历史数据表。如果你需要查询已经完成的任务、流程实例的耗时、审批记录的完整生命周期这个必须开。history-level有四个级别none不记录任何历史、activity只记录流程实例和活动节点的执行历史、audit记录所有流程实例、活动、任务、变量是默认推荐级别、full在audit基础上额外记录所有变量更新前后的值。我一般用audit就够full的存储膨胀速度非常快在数据量大的业务表上跑几天就能多几个G。async-executor-activate: true让Flowable的异步执行器接管定时器事件、异步任务等。如果关了流程里使用Timer Boundary Event或Async Continuation时节点会一直卡住不动。check-process-definitions和deployment-mode: default配合会在应用启动时自动扫描classpath:/processes/目录下的*.bpmn20.xml和*.bpmn文件作为新的流程定义部署到引擎里。这就是自动部署BPMN的机制的核心开关。有一点必须注意自动部署不等于自动更新已经存在的流程定义。Flowable的流程定义是按key和version区分的你不改文件直接重新部署新的BPMN会作为同一个key下的新版本插入但已启动的历史流程实例仍然按旧版本的流程定义执行。3.3 Java配置类开启注解和引擎Bean的覆盖点package com.example.demo.config; import org.flowable.spring.SpringProcessEngineConfiguration; import org.flowable.spring.boot.EngineConfigurationConfigurer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class FlowableConfig { Bean public EngineConfigurationConfigurerSpringProcessEngineConfiguration customProcessEngineConfigurer() { return config - { // 设置流程引擎的字符集防止中文流程名称或审批意见乱码 config.setXmlEncoding(UTF-8); // 流程实例启动时是否校验流程定义合法性 config.setEnableProcessDefinitionInfoCache(true); // 自定义ID生成器如果不想用Flowable默认的UUID主键可以替换 // config.setIdGenerator(new MyCustomIdGenerator()); }; } }这个配置类里最值得关注的是EngineConfigurationConfigurerSpringProcessEngineConfiguration回调机制。它是Flowable在Spring Boot自动配置完成后留给开发者的扩展点优先级最高可以覆盖自动配置里的几乎所有参数。比如你在application.yml里写死了history-level但在这里重新设置了config.setHistoryLevel()实际生效的是Java配置里的值。setXmlEncoding(UTF-8)这个看起来不起眼的设置在流程定义里如果有中文——比如流程名称、用户任务的name属性——而BPMN文件头部的?xml version1.0 encodingUTF-8?没有写encoding属性时可能导致中文乱码或解析失败。加上这个配置等于给所有流程定义统一加了编码兜底。3.4 启动时自动部署BPMN的前置条件Flowable的自动部署机制不是扫描到文件就完事它有前置条件文件必须放在process-definition-location-prefix配置的路径下默认是classpath:/processes/。文件名后缀必须匹配process-definition-location-suffixes里配的后缀。同一个process key的文件内容必须合法且有一个可解析的流程图结构。BPMN文件里定义的每个userTask、serviceTask引用的类或表达式必须在引擎扫描时就能加载到。如果某个BPMN文件格式有问题Flowable的启动不是跳过那个文件而是直接抛异常中断整个应用启动。这让很多第一次接触的人一头雾水明明是Spring Boot起不来日志里却看不到任何和业务代码相关的报错只有一堆XML解析错误。处理习惯是先写一个最小化的合法BPMN文件——只需要一个开始事件、一个结束事件——确认能正常启动部署后再逐步往里加用户任务和条件流。4. 新建流程的完整链路从BPMN建模到任务审批接口4.1 请假流程的BPMN文件在src/main/resources/processes/目录下新建leave.bpmn20.xml内容如下?xml version1.0 encodingUTF-8? definitions xmlnshttp://www.omg.org/spec/BPMN/20100524/MODEL xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:flowablehttp://flowable.org/bpmn targetNamespacehttp://www.flowable.org/test process idleaveProcess name请假审批流程 isExecutabletrue startEvent idstartEvent name发起请假/ userTask idmanagerTask name经理审批 flowable:assignee${manager}/ exclusiveGateway idoutcomeGateway name审批结果网关/ sequenceFlow idflow1 sourceRefstartEvent targetRefmanagerTask/ sequenceFlow idflow2 sourceRefmanagerTask targetRefoutcomeGateway/ endEvent idapprovedEnd name审批通过/ endEvent idrejectedEnd name审批拒绝/ sequenceFlow idflow3 sourceRefoutcomeGateway targetRefapprovedEnd conditionExpression xsi:typetFormalExpression ![CDATA[${approved true}]] /conditionExpression /sequenceFlow sequenceFlow idflow4 sourceRefoutcomeGateway targetRefrejectedEnd conditionExpression xsi:typetFormalExpression ![CDATA[${approved false}]] /conditionExpression /sequenceFlow /process /definitions这个模型的定义逻辑是发起人提交申请后流程进入经理审批节点经理通过或拒绝后由exclusiveGateway排他网关根据approved这个流程变量的值走不同分支。flowable:assignee${manager}表示该任务的处理人由流程变量manager动态指定这个变量在启动流程实例时传入。画BPMN的建议不要直接用Flowable自带的Modeler在线画图然后导出XML直接在IDE里写XML反而出错少。因为在线Modeler导出的文件会带bpmn2:documentation节点和一些自定义扩展属性在自动部署失败时排查更费劲。手写XML时保持结构最简能跑通后再加Timer、Multi Instance那些高级节点。4.2 启动流程实例并指定任务处理人package com.example.demo.service; import org.flowable.engine.RuntimeService; import org.flowable.engine.TaskService; import org.flowable.task.api.Task; import org.springframework.stereotype.Service; import java.util.HashMap; import java.util.Map; Service public class LeaveProcessService { private final RuntimeService runtimeService; private final TaskService taskService; public LeaveProcessService(RuntimeService runtimeService, TaskService taskService) { this.runtimeService runtimeService; this.taskService taskService; } /** * 启动请假审批流程 * param manager 经理ID或用户名 * return 流程实例ID */ public String startLeaveProcess(String applicant, String manager) { MapString, Object variables new HashMap(); variables.put(applicant, applicant); variables.put(manager, manager); return runtimeService.startProcessInstanceByKey(leaveProcess, variables).getId(); } /** * 查询某人名下的待办任务 */ public ListTask queryTasks(String assignee) { return taskService.createTaskQuery() .taskAssignee(assignee) .orderByTaskCreateTime() .desc() .list(); } /** * 完成审批任务 * param taskId 任务ID * param approved true通过, false拒绝 */ public void completeTask(String taskId, boolean approved) { MapString, Object variables new HashMap(); variables.put(approved, approved); taskService.complete(taskId, variables); } }接口代码里有几个关键参数要说明清楚runtimeService.startProcessInstanceByKey(leaveProcess)用的是流程定义key而不是ID好处是每次部署的新版本都会被这个key命中业务代码不用跟着流程版本号改。流程定义key对应BPMN文件里process idleaveProcess这个属性注意不要和name请假审批流程混了。taskService.createTaskQuery().taskAssignee(assignee)是按处理人查待办但实际业务里很多系统不是这样用的——任务不是提前指定给某个人的而是候选人candidate机制。如果你在BPMN里写的是flowable:candidateGroupsmanagerGroup查询就要改成.taskCandidateGroup(managerGroup)这样组里的每个人都看得到谁先认领谁就变成处理人。两者不要搞混否则前端页面上我的待办永远是空的。taskService.complete(taskId, variables)里的variables会绑定到当前任务的下一个节点表达式上。在上面这个流程里网关表达式${approved true}就是靠这个变量来判断的。注意complete之后流程不会立刻跑到目标节点引擎内部是异步推进的——除非你的流程同步执行没有异步器——所以调用完complete马上查历史表可能查不到已完成的记录要等一下再查。4.3 流程定义和流程实例的版本关系-- 查看已经部署的流程定义版本 SELECT ID_, KEY_, NAME_, VERSION_, DEPLOYMENT_ID_, RESOURCE_NAME_ FROM act_re_procdef WHERE KEY_ leaveProcess ORDER BY VERSION_ DESC; -- 查看进行中的流程实例 SELECT ID_, PROC_DEF_ID_, BUSINESS_KEY_, START_TIME_ FROM act_ru_execution WHERE PROC_DEF_ID_ LIKE %leaveProcess% AND IS_ACTIVE_ 1;每次自动部署新的BPMN文件后act_re_procdef里会多一条同key新版本的记录。这里有个经典的坑新部署的流程定义不会影响已经在跑的旧流程实例它们继续按旧版本执行。如果业务上需要所有的审批单必须走新版流程规则只能在天级别的维护窗口里把未完成实例手动终止runtimeService.deleteProcessInstance(processInstanceId, forced termination)没有别的后悔药。act_ru_execution表记录的是正在执行的实例节点信息IS_ACTIVE_ 1表示流程还没走到终节点。如果一条流程实例运行完了但还留在act_ru_execution里大概率是你没有正确配置history-level: audit或者异步任务卡住了。4.4 把任务列表接到前端接口时的参数处理前端展示待办列表时通常需要把任务关联的业务表单数据一起返回。这时你查完Task后还需要用RuntimeService.getVariable(taskId, applicant)或直接查act_ru_variable把流程变量带出来。不要图省事一次性查所有任务的变量——taskService.getVariables(taskId)只返回当前任务关联的local变量全局变量要走到runtimeService那边。抄近路的后果是列表页变量对不上前端逻辑出现各种玄学现象。每页翻页建议用listPage(firstResult, maxResults)而不是list()list()在数据超过几千条时会一把梭全查回来内存直接吃紧。排序字段用orderByTaskCreateTime().desc()这是待办列表最合理的默认排序。5. 避坑指南Flowable整合中最容易翻车的五个细节5.1 启动报错Public Key Retrieval is not allowed现象Spring Boot启动时数据库连接池初始化直接报错日志里出现Public Key Retrieval is not allowed。原因MySQL 8默认使用caching_sha2_password认证插件而JDBC驱动在连接阶段无法自动获取服务器端的公钥来加密密码传输。解决在JDBC连接串上加参数allowPublicKeyRetrievaltrue。这个参数在MySQL 8.0.x版本下几乎是必加的除非你把用户的认证插件改回mysql_native_password。适当的SQL是ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY root; FLUSH PRIVILEGES;注意这里改的是认证方式不是密码强度密码重置后要同步修改application.yml。5.2 索引超长Specified key was too long现象Flowable第一次创建ACT_开头的表时直接失败日志提示Index column size too long或Specified key was too long; max key length is 767 bytes。原因MySQL 5.7的InnoDB在utf8mb4编码下默认索引长度限制是767字节。Flowable的ACT_RU_JOB表的HANDLER_TYPE_字段上有索引字段长度在utf8mb4下乘以4就会超限。解决这个坑在老版本MySQL上很常见但在8.0里默认每列是3072字节所以直接用资源里自带的MySQL 8安装程序或者确保线上库是8.0版本。如果你的生产环境还在MySQL 5.7就把database-schema-update关闭DBA手工执行建表SQL并把相关表的ROW_FORMAT改成DYNAMIC。5.3 启动无限报错BPMN文件有格式问题导致应用起不来现象应用启动到一半Spring容器初始化Flowable引擎时报XMLException提示cvc-complex-type.2.4.a: Invalid content was found starting with element documentation。原因BPMN文件的XML Schema校验失败通常发生在文件里有多余的命名空间声明或节点顺序不对。手写的XML最容易出现的问题是把documentation节点放在definitions下而不是process下或者sequenceFlow的sourceRef写得和节点的id对不上。解决先在IDE里用XML校验插件检查文件或者删掉documentation节点和不需要的命名空间保留最简结构。同时确认BPMN文件放在classpath:/processes/下后缀匹配.bpmn20.xml。文件不合法就别指望引擎自动跳过它一定会中断启动来提醒你。5.4 任务一直停在UserTask上不往下走现象审批人点了通过前端显示任务已完成但流程实例状态还是活的后续节点不触发。原因一种是complete(taskId)后没有设置网关需要的变量网关表达式无变量可用流程卡在选择分支上另一种是使用了异步任务flowable:asynctrue而异步执行器没有配置开启。解决先确认配置里async-executor-activate: true再检查complete时传入的变量名和网关conditionExpression里引用的变量名是否一致——比如你传的是approveResult表达式里写的是${approved true}那一定匹配不上。这里可以使用Flowable自带的ManagementService.createJobQuery()看一下有没有执行失败的job这是排查这类问题的第一手段。5.5 MySQL 8自带的安装程序和已有的旧实例冲突现象运行资源里自带的MySQL 8安装程序提示服务已经存在或者端口3306被占用安装完成后root密码不是你以为的那个。原因机器上已经装过MySQL 5.7或其他版本的MySQL服务安装程序默认的服务名或端口冲突。另一个常见情况是安装过程中手动指定了数据目录但服务启动账户对该目录无权限导致MySQL服务根本起不来。解决有旧实例就先卸载干净或者安装时改成一个独立服务名和数据目录比如服务名MySQL8端口3307。因为多个MySQL实例可以在同一台机器上并存只要服务名和端口错开就互不干扰。安装完成后服务起来了再执行mysql -uroot -p验证连通性确认能连上再启动Spring Boot应用。6. 上线前的验证方法用自带REST接口和SQL把整套环境跑通再交底把Spring Boot应用跑起来真的只是第一步。我一般会在正式提交给测试之前按顺序跑完一套最核心的验证流程——这能直接筛掉上面那一堆环境、版本、配置层面的问题。第一步验证MySQL服务确实是8.0。启动后执行SELECT VERSION();如果返回内容里带8.0.x字样说明数据库环境是符合这套整合包预期的。这一步看似多余但很多后端开发者在同事的机器上跑得好好的换到自己电脑上就启动报错最后查出来是本地装的是MySQL 5.6。第二步不看Spring Boot控制台日志而是先确认数据库里Flowable表是否建全了。运行这段SQLSELECT COUNT(*) AS table_count FROM information_schema.tables WHERE table_schema flowable AND table_name LIKE ACT\_%;正常情况下这个数应该在50以上。如果为0说明database-schema-update: true可能没生效或者应用没有真正连上这个库。这时候不要再急着看代码先去确认连接串里写的库名和实际MySQL里的库名是否一致这是个最常见的低级错误。第三步走一遍流程的完整闭环这也算是对上一章那些坑的综合验证。先在浏览器访问http://localhost:8080/process-api/repository/process-definitions?keyleaveProcess这个REST接口会返回流程定义的元数据重点关注返回体里有没有version: 1。没有版本信息说明你的BPMN文件根本没被部署成功。然后再用RuntimeService启动一条流程主动完成审批检查act_hi_procinst表里这条记录的END_TIME_是否被写入写入了说明历史归档正常。关于性能参数我一般会在测试通过后统一做一轮调整act_ru_task表走正常的索引策略不加额外索引act_hi_actinst这种历史表会加一个PROC_INST_ID_的单列索引因为这是按流程实例查历史时最高频的条件。Flowable自带的表结构里虽然有一些索引但在大数据量下往往不够用只靠引擎默认索引跑报表查询是会有卡顿的。这部分改动不要通过application.yml去配而是直接在数据库管理工具里执行CREATE INDEX语句放进统一的数据库变更脚本里管理。从那以后我每次拿到一个Flowable整合包都会强制自己先跑一遍这三个验证步骤确认表建全、流程定义注册成功、审批链路闭环才开始动手写业务代码。这个习惯帮我挡掉了很多在我这是好的的甩锅场景。希望这篇拆解过的整合包笔记能帮你在Flowable接入这条路上少走几步弯路至少不要把时间花在那些已经可以提前规避的环境和配置问题上。如果你当前的项目正好卡在Spring Boot版本和Flowable版本不兼容的僵局里这个自带MySQL 8安装程序的Spring Boot 2.6.13 Flowable 6.8.1资源包应该是能直接落地的方案拿它做起点比从零开始拼版本靠谱得多。本文还有配套的精品资源点击获取 Flowable 6.8.1整合Spring Boot审批流：配置、部署与避坑实践
简介一套基于Spring Boot 2.6.13、MySQL 8和Flowable 6.8.1的完整工程项目面向需要快速搭建工作流平台的Java后端开发者解决BPM流程引擎与业务系统集成时的环境配置难题。压缩包共29个文件包括java源码、class编译文件、xml配置、yml环境配置、pom及properties文件并附带MySQL 8官方安装程序总大小382.9MB目录结构完整适合导入IDE直接构建。目前已有108人学习下载适合在本地快速搭建演示环境也可作为二次开发的起点。项目自带MySQL安装程序免去单独安装数据库的繁琐步骤同时包含Flowable流程设计的核心代码和配置文件开发者可快速理解Spring Boot如何整合Flowable并基于BPMN 2.0进行流程定义、任务管理和表单管理。读者还能参考项目中的RESTful接口设计与ORM交互方式降低工作流功能落地的门槛。1. 拿Flowable 6.8.1做审批流Spring Boot 2.6.13整合工作流为什么我建议直接抄这套配置做后台管理系统但凡业务里带审批两个字——请假、报销、合同会签、采购验收——迟早要碰工作流引擎。Flowable是目前国内中小团队用得最多的开源工作流方案之一但它的坑也最集中版本兼容、表结构初始化、流程部署方式、历史数据保留策略任何一个环节没对齐启动就直接报错。我拆过不少号称开箱即用的整合包真正能拿下来一条审批流程从头跑到结束的这套Spring Boot 2.6.13 MySQL 8.0 Flowable 6.8.1的组合算是比较省心的尤其它还自带了MySQL 8安装程序省掉了测试环境数据库版本不一致导致的脏数据问题。这篇笔记适合两类人一是刚接手Spring Boot项目、需要在三天内把工作流引擎跑起来并画出第一条请假流程的开发者二是已经在用Activiti或老版本Flowable想迁移到6.x并踩过版本兼容坑的熟手。文章会从版本选型讲到BPMN建模、引擎配置、任务审批接口最后收在验证和二次开发习惯上全程按可复现的标准写命令和代码直接抄。2. 为什么是Flowable 6.8.1版本兼容边界和引擎选型逻辑2.1 Spring Boot 2.6.x和Flowable 6.8.1的兼容性边界Flowable的版本和Spring Boot版本不是一一对应的官方虽然提供了starter但底层对Spring Boot版本的适配程度是分层的。Flowable 6.8.1这个版本在设计上对应的Spring Boot版本是2.6.x和2.7.x它用到了Spring Framework 5.3.x的特性对Spring Boot 3.x的Jakarta命名空间完全不兼容。所以如果你的项目基建已经升级到Spring Boot 3就不要在这个整合包上硬套需要另外找Flowable 7.x的方案。这里有一个容易被忽略的细节Flowable 6.8.1的flowable-spring-boot-starter会传递依赖Spring Boot的spring-boot-autoconfigure如果项目里同时存在其他starter版本仲裁可能导致Spring Boot被降级或升级。我在一个老项目里遇到过flowable-spring-boot-starter把Spring Boot从2.7.5拉到2.6.2的情况原因就是父POM里没有锁定Spring Boot版本号。解决方法是在pom.xml的dependencyManagement里显式声明spring-boot-dependencies版本用2.6.13让Maven的依赖仲裁以父POM为准。不要小看这个版本锁定问题。工作流引擎启动时要做的事情非常多——检查数据库连接、创建ACT_开头的表、初始化引擎配置、扫描并部署classpath下的BPMN文件——任何一个底层依赖的类加载异常都会在ProcessEngine创建阶段以ExceptionInInitializerError的形式暴露出来而且错误日志往往指向一些非常底层的库比如mybatis或ibatis的类不看依赖树根本定位不到根因。2.2 Starter包和ProcessEngine独立构建的差别整合Flowable有两种主流方式第一种是直接用官方starter第二种是只引入flowable-engine核心包自己创建ProcessEngine。官方starter的方式是引入flowable-spring-boot-starter-process后Spring容器会自动创建ProcessEngine、RepositoryService、RuntimeService、TaskService等Bean并且自动处理事务和懒加载。这种方式对大多数业务系统够用缺点是自动配置的过程像一个黑匣子——你不知道哪些Bean被创建了、哪些配置被覆盖了。自己构建ProcessEngine的方式更可控但代码量多还要自己管理事务边界和Spring的整合。我的建议是如果项目是从零开始直接走官方starter把自动配置的优先级搞清楚踩坑概率更低如果项目里已经有一个Flowable引擎在跑要整合到新的Spring Boot应用里才考虑手动构建因为这时候你可能需要同时维护两套数据源或两套引擎配置。这套资源在基石设计上走的是starter路线但它把MySQL 8安装程序也打包进来了这就意味着引擎的初始化环境是固定的标准MySQL 8而不是你来路不明的旧版本MySQL 5.7。在Flowable 6.x里MySQL 5.7和8.0的表结构初始化有一点差异尤其是ACT_RU_JOB表对时间字段的处理和索引长度限制5.7默认的utf8mb4配置可能导致索引长度超限Specified key was too long在8.0里则没有这个问题。所以这个资源自带MySQL 8安装程序等于提前把一个常见的环境坑给填了。2.3 Flowable每个核心Service在项目里的真实分工Flowable跑起来以后Spring容器里有五个最常见的Service新手容易弄混RepositoryService管流程定义的部署和查询就是你画的BPMN文件存到了哪里RuntimeService管流程实例的启动、删除、触发相当于流程的运行时指挥中心TaskService管待办任务——查询、认领、完成、转办HistoryService管历史数据包括已完成的流程实例、历史任务、活动记录IdentityService管用户和组但大多数情况下咱们不会真的往Flowable里同步用户都是业务系统自己管理用户代码里通过TaskService.setAssignee()来指定处理人。我在实际项目里的分工是流程部署和版本管理走RepositoryService和act_rep_procdef表待办列表查询永远走TaskService.createTaskQuery()这比直接查ACT_RU_TASK表安全得多因为Flowable的查询API会自己处理数据权限和变量条件历史归档走HistoryService但只保留业务需要的数据不要把引擎自带的全量历史数据都堆在线上库里。3. Spring Boot整合Flowable配置项逐项拆解和引擎初始化落地3.1 核心依赖和MySQL 8安装环境先把pom.xml的依赖写全需要注意的地方我会在代码块后面说明。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.6.13/version relativePath/ /parent properties java.version1.8/java.version flowable.version6.8.1/flowable.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version scoperuntime/scope /dependency dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter-process/artifactId version${flowable.version}/version /dependency dependency groupIdorg.flowable/groupId artifactIdflowable-spring-boot-starter-rest/artifactId version${flowable.version}/version /dependency /dependenciesflowable-spring-boot-starter-process是这个整合包最核心的依赖它负责引擎的自动配置和Spring事务集成。flowable-spring-boot-starter-rest是可选的但如果你的前端需要通过REST接口直接操作系统里的流程数据——比如流程定义列表、模型列表——这个依赖可以把Flowable自带的REST API暴露出来。注意这个REST API默认的访问路径是/process-api而且它是没有做权限控制的生产环境一定要加Spring Security过滤掉这个路径或者直接不引入这个starter。MySQL Connector的版本这里用的是mysql-connector-jMySQL官方在8.0.31之后把mysql-connector-java重命名成了mysql-connector-jgroupId也要改成com.mysql。如果沿用老的mysql-connector-java写法在Maven中央仓库虽然还能拉到但会遇到Public Key Retrieval is not allowed的经典报错后面避坑章节我会具体展开。资源里自带的MySQL 8安装程序建议在Windows测试机上直接以默认配置安装到位。安装完成后记得在服务里确认MySQL服务是自动启动状态并且把root用户的密码设置成好记的固定值因为在下面的数据源配置里会用到。3.2 application.yml里Flowable相关的参数逐个说明server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/flowable?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 flowable: database-schema-update: true db-history-used: true history-level: audit async-executor-activate: true check-process-definitions: true deployment-mode: default process-definition-location-prefix: classpath:/processes/ process-definition-location-suffixes: - .bpmn20.xml - .bpmndatabase-schema-update: true的意思是允许Flowable在启动时自动建表或升级表结构。这个值在生产环境建议改成false由DBA统一管理数据库变更但在开发测试阶段保持true是最省心的——你换了新版本的Flowable引擎或者增加了一张业务表重启应用后引擎会自动补齐缺失的表。db-history-used: true决定是否启用历史数据表。如果你需要查询已经完成的任务、流程实例的耗时、审批记录的完整生命周期这个必须开。history-level有四个级别none不记录任何历史、activity只记录流程实例和活动节点的执行历史、audit记录所有流程实例、活动、任务、变量是默认推荐级别、full在audit基础上额外记录所有变量更新前后的值。我一般用audit就够full的存储膨胀速度非常快在数据量大的业务表上跑几天就能多几个G。async-executor-activate: true让Flowable的异步执行器接管定时器事件、异步任务等。如果关了流程里使用Timer Boundary Event或Async Continuation时节点会一直卡住不动。check-process-definitions和deployment-mode: default配合会在应用启动时自动扫描classpath:/processes/目录下的*.bpmn20.xml和*.bpmn文件作为新的流程定义部署到引擎里。这就是自动部署BPMN的机制的核心开关。有一点必须注意自动部署不等于自动更新已经存在的流程定义。Flowable的流程定义是按key和version区分的你不改文件直接重新部署新的BPMN会作为同一个key下的新版本插入但已启动的历史流程实例仍然按旧版本的流程定义执行。3.3 Java配置类开启注解和引擎Bean的覆盖点package com.example.demo.config; import org.flowable.spring.SpringProcessEngineConfiguration; import org.flowable.spring.boot.EngineConfigurationConfigurer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class FlowableConfig { Bean public EngineConfigurationConfigurerSpringProcessEngineConfiguration customProcessEngineConfigurer() { return config - { // 设置流程引擎的字符集防止中文流程名称或审批意见乱码 config.setXmlEncoding(UTF-8); // 流程实例启动时是否校验流程定义合法性 config.setEnableProcessDefinitionInfoCache(true); // 自定义ID生成器如果不想用Flowable默认的UUID主键可以替换 // config.setIdGenerator(new MyCustomIdGenerator()); }; } }这个配置类里最值得关注的是EngineConfigurationConfigurerSpringProcessEngineConfiguration回调机制。它是Flowable在Spring Boot自动配置完成后留给开发者的扩展点优先级最高可以覆盖自动配置里的几乎所有参数。比如你在application.yml里写死了history-level但在这里重新设置了config.setHistoryLevel()实际生效的是Java配置里的值。setXmlEncoding(UTF-8)这个看起来不起眼的设置在流程定义里如果有中文——比如流程名称、用户任务的name属性——而BPMN文件头部的?xml version1.0 encodingUTF-8?没有写encoding属性时可能导致中文乱码或解析失败。加上这个配置等于给所有流程定义统一加了编码兜底。3.4 启动时自动部署BPMN的前置条件Flowable的自动部署机制不是扫描到文件就完事它有前置条件文件必须放在process-definition-location-prefix配置的路径下默认是classpath:/processes/。文件名后缀必须匹配process-definition-location-suffixes里配的后缀。同一个process key的文件内容必须合法且有一个可解析的流程图结构。BPMN文件里定义的每个userTask、serviceTask引用的类或表达式必须在引擎扫描时就能加载到。如果某个BPMN文件格式有问题Flowable的启动不是跳过那个文件而是直接抛异常中断整个应用启动。这让很多第一次接触的人一头雾水明明是Spring Boot起不来日志里却看不到任何和业务代码相关的报错只有一堆XML解析错误。处理习惯是先写一个最小化的合法BPMN文件——只需要一个开始事件、一个结束事件——确认能正常启动部署后再逐步往里加用户任务和条件流。4. 新建流程的完整链路从BPMN建模到任务审批接口4.1 请假流程的BPMN文件在src/main/resources/processes/目录下新建leave.bpmn20.xml内容如下?xml version1.0 encodingUTF-8? definitions xmlnshttp://www.omg.org/spec/BPMN/20100524/MODEL xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:flowablehttp://flowable.org/bpmn targetNamespacehttp://www.flowable.org/test process idleaveProcess name请假审批流程 isExecutabletrue startEvent idstartEvent name发起请假/ userTask idmanagerTask name经理审批 flowable:assignee${manager}/ exclusiveGateway idoutcomeGateway name审批结果网关/ sequenceFlow idflow1 sourceRefstartEvent targetRefmanagerTask/ sequenceFlow idflow2 sourceRefmanagerTask targetRefoutcomeGateway/ endEvent idapprovedEnd name审批通过/ endEvent idrejectedEnd name审批拒绝/ sequenceFlow idflow3 sourceRefoutcomeGateway targetRefapprovedEnd conditionExpression xsi:typetFormalExpression ![CDATA[${approved true}]] /conditionExpression /sequenceFlow sequenceFlow idflow4 sourceRefoutcomeGateway targetRefrejectedEnd conditionExpression xsi:typetFormalExpression ![CDATA[${approved false}]] /conditionExpression /sequenceFlow /process /definitions这个模型的定义逻辑是发起人提交申请后流程进入经理审批节点经理通过或拒绝后由exclusiveGateway排他网关根据approved这个流程变量的值走不同分支。flowable:assignee${manager}表示该任务的处理人由流程变量manager动态指定这个变量在启动流程实例时传入。画BPMN的建议不要直接用Flowable自带的Modeler在线画图然后导出XML直接在IDE里写XML反而出错少。因为在线Modeler导出的文件会带bpmn2:documentation节点和一些自定义扩展属性在自动部署失败时排查更费劲。手写XML时保持结构最简能跑通后再加Timer、Multi Instance那些高级节点。4.2 启动流程实例并指定任务处理人package com.example.demo.service; import org.flowable.engine.RuntimeService; import org.flowable.engine.TaskService; import org.flowable.task.api.Task; import org.springframework.stereotype.Service; import java.util.HashMap; import java.util.Map; Service public class LeaveProcessService { private final RuntimeService runtimeService; private final TaskService taskService; public LeaveProcessService(RuntimeService runtimeService, TaskService taskService) { this.runtimeService runtimeService; this.taskService taskService; } /** * 启动请假审批流程 * param manager 经理ID或用户名 * return 流程实例ID */ public String startLeaveProcess(String applicant, String manager) { MapString, Object variables new HashMap(); variables.put(applicant, applicant); variables.put(manager, manager); return runtimeService.startProcessInstanceByKey(leaveProcess, variables).getId(); } /** * 查询某人名下的待办任务 */ public ListTask queryTasks(String assignee) { return taskService.createTaskQuery() .taskAssignee(assignee) .orderByTaskCreateTime() .desc() .list(); } /** * 完成审批任务 * param taskId 任务ID * param approved true通过, false拒绝 */ public void completeTask(String taskId, boolean approved) { MapString, Object variables new HashMap(); variables.put(approved, approved); taskService.complete(taskId, variables); } }接口代码里有几个关键参数要说明清楚runtimeService.startProcessInstanceByKey(leaveProcess)用的是流程定义key而不是ID好处是每次部署的新版本都会被这个key命中业务代码不用跟着流程版本号改。流程定义key对应BPMN文件里process idleaveProcess这个属性注意不要和name请假审批流程混了。taskService.createTaskQuery().taskAssignee(assignee)是按处理人查待办但实际业务里很多系统不是这样用的——任务不是提前指定给某个人的而是候选人candidate机制。如果你在BPMN里写的是flowable:candidateGroupsmanagerGroup查询就要改成.taskCandidateGroup(managerGroup)这样组里的每个人都看得到谁先认领谁就变成处理人。两者不要搞混否则前端页面上我的待办永远是空的。taskService.complete(taskId, variables)里的variables会绑定到当前任务的下一个节点表达式上。在上面这个流程里网关表达式${approved true}就是靠这个变量来判断的。注意complete之后流程不会立刻跑到目标节点引擎内部是异步推进的——除非你的流程同步执行没有异步器——所以调用完complete马上查历史表可能查不到已完成的记录要等一下再查。4.3 流程定义和流程实例的版本关系-- 查看已经部署的流程定义版本 SELECT ID_, KEY_, NAME_, VERSION_, DEPLOYMENT_ID_, RESOURCE_NAME_ FROM act_re_procdef WHERE KEY_ leaveProcess ORDER BY VERSION_ DESC; -- 查看进行中的流程实例 SELECT ID_, PROC_DEF_ID_, BUSINESS_KEY_, START_TIME_ FROM act_ru_execution WHERE PROC_DEF_ID_ LIKE %leaveProcess% AND IS_ACTIVE_ 1;每次自动部署新的BPMN文件后act_re_procdef里会多一条同key新版本的记录。这里有个经典的坑新部署的流程定义不会影响已经在跑的旧流程实例它们继续按旧版本执行。如果业务上需要所有的审批单必须走新版流程规则只能在天级别的维护窗口里把未完成实例手动终止runtimeService.deleteProcessInstance(processInstanceId, forced termination)没有别的后悔药。act_ru_execution表记录的是正在执行的实例节点信息IS_ACTIVE_ 1表示流程还没走到终节点。如果一条流程实例运行完了但还留在act_ru_execution里大概率是你没有正确配置history-level: audit或者异步任务卡住了。4.4 把任务列表接到前端接口时的参数处理前端展示待办列表时通常需要把任务关联的业务表单数据一起返回。这时你查完Task后还需要用RuntimeService.getVariable(taskId, applicant)或直接查act_ru_variable把流程变量带出来。不要图省事一次性查所有任务的变量——taskService.getVariables(taskId)只返回当前任务关联的local变量全局变量要走到runtimeService那边。抄近路的后果是列表页变量对不上前端逻辑出现各种玄学现象。每页翻页建议用listPage(firstResult, maxResults)而不是list()list()在数据超过几千条时会一把梭全查回来内存直接吃紧。排序字段用orderByTaskCreateTime().desc()这是待办列表最合理的默认排序。5. 避坑指南Flowable整合中最容易翻车的五个细节5.1 启动报错Public Key Retrieval is not allowed现象Spring Boot启动时数据库连接池初始化直接报错日志里出现Public Key Retrieval is not allowed。原因MySQL 8默认使用caching_sha2_password认证插件而JDBC驱动在连接阶段无法自动获取服务器端的公钥来加密密码传输。解决在JDBC连接串上加参数allowPublicKeyRetrievaltrue。这个参数在MySQL 8.0.x版本下几乎是必加的除非你把用户的认证插件改回mysql_native_password。适当的SQL是ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY root; FLUSH PRIVILEGES;注意这里改的是认证方式不是密码强度密码重置后要同步修改application.yml。5.2 索引超长Specified key was too long现象Flowable第一次创建ACT_开头的表时直接失败日志提示Index column size too long或Specified key was too long; max key length is 767 bytes。原因MySQL 5.7的InnoDB在utf8mb4编码下默认索引长度限制是767字节。Flowable的ACT_RU_JOB表的HANDLER_TYPE_字段上有索引字段长度在utf8mb4下乘以4就会超限。解决这个坑在老版本MySQL上很常见但在8.0里默认每列是3072字节所以直接用资源里自带的MySQL 8安装程序或者确保线上库是8.0版本。如果你的生产环境还在MySQL 5.7就把database-schema-update关闭DBA手工执行建表SQL并把相关表的ROW_FORMAT改成DYNAMIC。5.3 启动无限报错BPMN文件有格式问题导致应用起不来现象应用启动到一半Spring容器初始化Flowable引擎时报XMLException提示cvc-complex-type.2.4.a: Invalid content was found starting with element documentation。原因BPMN文件的XML Schema校验失败通常发生在文件里有多余的命名空间声明或节点顺序不对。手写的XML最容易出现的问题是把documentation节点放在definitions下而不是process下或者sequenceFlow的sourceRef写得和节点的id对不上。解决先在IDE里用XML校验插件检查文件或者删掉documentation节点和不需要的命名空间保留最简结构。同时确认BPMN文件放在classpath:/processes/下后缀匹配.bpmn20.xml。文件不合法就别指望引擎自动跳过它一定会中断启动来提醒你。5.4 任务一直停在UserTask上不往下走现象审批人点了通过前端显示任务已完成但流程实例状态还是活的后续节点不触发。原因一种是complete(taskId)后没有设置网关需要的变量网关表达式无变量可用流程卡在选择分支上另一种是使用了异步任务flowable:asynctrue而异步执行器没有配置开启。解决先确认配置里async-executor-activate: true再检查complete时传入的变量名和网关conditionExpression里引用的变量名是否一致——比如你传的是approveResult表达式里写的是${approved true}那一定匹配不上。这里可以使用Flowable自带的ManagementService.createJobQuery()看一下有没有执行失败的job这是排查这类问题的第一手段。5.5 MySQL 8自带的安装程序和已有的旧实例冲突现象运行资源里自带的MySQL 8安装程序提示服务已经存在或者端口3306被占用安装完成后root密码不是你以为的那个。原因机器上已经装过MySQL 5.7或其他版本的MySQL服务安装程序默认的服务名或端口冲突。另一个常见情况是安装过程中手动指定了数据目录但服务启动账户对该目录无权限导致MySQL服务根本起不来。解决有旧实例就先卸载干净或者安装时改成一个独立服务名和数据目录比如服务名MySQL8端口3307。因为多个MySQL实例可以在同一台机器上并存只要服务名和端口错开就互不干扰。安装完成后服务起来了再执行mysql -uroot -p验证连通性确认能连上再启动Spring Boot应用。6. 上线前的验证方法用自带REST接口和SQL把整套环境跑通再交底把Spring Boot应用跑起来真的只是第一步。我一般会在正式提交给测试之前按顺序跑完一套最核心的验证流程——这能直接筛掉上面那一堆环境、版本、配置层面的问题。第一步验证MySQL服务确实是8.0。启动后执行SELECT VERSION();如果返回内容里带8.0.x字样说明数据库环境是符合这套整合包预期的。这一步看似多余但很多后端开发者在同事的机器上跑得好好的换到自己电脑上就启动报错最后查出来是本地装的是MySQL 5.6。第二步不看Spring Boot控制台日志而是先确认数据库里Flowable表是否建全了。运行这段SQLSELECT COUNT(*) AS table_count FROM information_schema.tables WHERE table_schema flowable AND table_name LIKE ACT\_%;正常情况下这个数应该在50以上。如果为0说明database-schema-update: true可能没生效或者应用没有真正连上这个库。这时候不要再急着看代码先去确认连接串里写的库名和实际MySQL里的库名是否一致这是个最常见的低级错误。第三步走一遍流程的完整闭环这也算是对上一章那些坑的综合验证。先在浏览器访问http://localhost:8080/process-api/repository/process-definitions?keyleaveProcess这个REST接口会返回流程定义的元数据重点关注返回体里有没有version: 1。没有版本信息说明你的BPMN文件根本没被部署成功。然后再用RuntimeService启动一条流程主动完成审批检查act_hi_procinst表里这条记录的END_TIME_是否被写入写入了说明历史归档正常。关于性能参数我一般会在测试通过后统一做一轮调整act_ru_task表走正常的索引策略不加额外索引act_hi_actinst这种历史表会加一个PROC_INST_ID_的单列索引因为这是按流程实例查历史时最高频的条件。Flowable自带的表结构里虽然有一些索引但在大数据量下往往不够用只靠引擎默认索引跑报表查询是会有卡顿的。这部分改动不要通过application.yml去配而是直接在数据库管理工具里执行CREATE INDEX语句放进统一的数据库变更脚本里管理。从那以后我每次拿到一个Flowable整合包都会强制自己先跑一遍这三个验证步骤确认表建全、流程定义注册成功、审批链路闭环才开始动手写业务代码。这个习惯帮我挡掉了很多在我这是好的的甩锅场景。希望这篇拆解过的整合包笔记能帮你在Flowable接入这条路上少走几步弯路至少不要把时间花在那些已经可以提前规避的环境和配置问题上。如果你当前的项目正好卡在Spring Boot版本和Flowable版本不兼容的僵局里这个自带MySQL 8安装程序的Spring Boot 2.6.13 Flowable 6.8.1资源包应该是能直接落地的方案拿它做起点比从零开始拼版本靠谱得多。本文还有配套的精品资源点击获取