很多做Java后端的朋友都遇到过这样一个场景业务系统里已经有一套基于状态字段的审批逻辑代码里写满switch-case每加一个审批节点就要改流程代码、改数据库表结构、再发一版上线时间一长根本不敢碰那一坨逻辑。我在两个项目里经历过同样的痛苦之后把Spring Boot项目里的审批模块重构成了基于Activiti工作流引擎的实现这篇文章就把整个重塑过程、踩坑记录、以及整合落地时的关键决策全部写出来供同样被审批逻辑折磨的人参考。先说清楚这篇文章不是把Activiti官方文档翻译一遍而是以“在Spring Boot里把Activiti真正用起来”为主线内容覆盖版本选型、BPMN流程设计、引擎与Spring Boot的集成方式、核心服务API的组合用法、四层架构下的代码落位、以及数据库和监控相关的高频坑点。不管你是在做OA审批、工单流转、还是业务订单状态机这套思路都可以直接借鉴。1. 为什么是Activiti先搞懂它和手写状态机的本质区别1.1 手写状态机的痛以及工作流引擎替代它的理由很多团队在项目初期都会选择手写状态机来处理审批流程。一张表加一个status字段Service层写一堆if-else判断当前状态能往哪里流转配上几张关联表记录审批人和审批意见。这套方案在流程固定、节点少于五六个、变更频率极低的时候确实够用。但我遇到的实际情况是流程变更永远比预期频繁而且变更总是发生在项目上线之后。产品经理今天要加一个“部门总监审批超过48小时自动转交副总”的规则明天要把“财务复核”插入到“人事审批”之前手写状态机每次都要改代码、写迁移脚本、重新回归测试改一次伤一次。Activiti这类工作流引擎的核心价值就是把“流程走向”从业务代码里彻底剥离出去。业务流程被建模成一份BPMN 2.0标准的XML文件引擎负责加载这份XML、解释节点和连线、持久化流程实例和任务数据。业务代码不再关心“下一个节点是谁”“什么条件下走哪个分支”只负责调用API触发流转以及在合适的节点执行具体的业务动作。这样一来流程调整只需要改BPMN文件重新部署Class换个版本号不用动Java代码。1.2 Activiti、Flowable、Camunda到底怎么选很多人在选型时会拿Activiti和Flowable、Camunda做对比。我的看法是如果项目已经决定用Activiti那大概率看重的是它和Spring Boot的亲和度、社区资料丰富度、以及国内中小团队积累的大量踩坑经验。Flowable是Activiti 5的分支衍生而来内核相近文档也很全但社区活跃度和中文资料比Activiti略少。Camunda功能更强大自带漂亮的Cockpit监控界面适合复杂编排场景但学习曲线明显更陡对中小项目来说有点杀鸡用牛刀。从生态角度看Activiti 7之后的版本和Spring Boot 2.x/3.x的整合做得比较顺官方提供了activiti-spring-boot-starter依赖写进去就能自动配置DataSource、ProcessEngine、RuntimeService等核心Bean。这一点非常关键——它意味着你不用像老版本Activiti 5那样自己写一堆XML配置来装配引擎。如果你的团队已经会用Spring Boot那Activiti的入门成本会低很多。注意Activiti 5和Activiti 6的老项目里很多人是自己定义ProcessEngineConfiguration来构建引擎这种方式在Spring Boot 2.4之后经常遇到兼容问题。新项目一律建议使用官方starter把版本控制交给Maven/Gradle的BOM。1.3 Activiti能做什么以及它不擅长做什么Activiti擅长的是有向流程编排串行审批、并行会签、条件分支、子流程调用、定时触发、事件监听这些能力天生就有。它还负责维护流程状态包括流程实例当前停留在哪个节点、哪些任务被创建、谁处理过哪些任务、每个人的审批意见是什么。这些数据全都持久化到ACT_前缀的几十张表里。但要注意Activiti不是业务规则引擎也不是定时任务框架。复杂的业务规则建议交给规则引擎纯定时任务建议直接上Quartz或Spring自带的Scheduled。Activiti里的定时器能力虽然有但只适合处理流程内部的延时事件比如超时未审批自动通过别拿它当任务调度中心用。这个定位想清楚后面设计流程时就不会把什么东西都往BPMN里塞。2. 版本选型与依赖落地兼容性矩阵、数据库版本与IDEA插件2.1 Spring Boot与Activiti的版本配对关系版本选型是我被问得最多的问题也是踩坑重灾区。Activiti的版本更新节奏和Spring Boot不完全同步直接套用最新版本经常遇到NoSuchBeanDefinitionException或自动配置不生效的问题。以我目前在用的实际组合为例Spring Boot版本Activiti版本说明2.3.x ~ 2.5.x7.1.0.M6 / 7.1.0.M4这是我试过最稳的搭配依赖冲突少2.6.x ~ 2.7.x7.1.0.M6需要额外注意spring-boot-autoconfigure版本兼容3.x7.1.0.M6或更高Spring Boot 3基于Jakarta命名空间需要确认Activiti是否已适配生产项目不要追求最新版本。Activiti 7的正式版迭代节奏相对较慢很多企业项目至今跑在6.x版本上但6.x和Spring Boot 2.x整合需要手动排除冲突复杂度高一些。我的建议很直接Spring Boot 2.7 Activiti 7.1.0.M6是经过大量生产验证的稳妥组合日志不报错自动配置全部生效资料搜得到踩过的坑都有人趟过。pom.xml的核心依赖配置如下dependency groupIdorg.activiti/groupId artifactIdactiviti-spring-boot-starter/artifactId version7.1.0.M6/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency很多初学者只引入activiti-spring-boot-starter这一个依赖结果启动时报找不到DataSource。这个starter内部默认依赖Spring JDBC但如果你用的是Spring Boot 2.7建议显式加上spring-boot-starter-jdbc避免某些场景下类没有被正确加载。2.2 数据库选择与Activiti自动建表的机制Activiti运行时会在数据库里创建约50张ACT_开头的表包括流程定义表ACT_RE_PROCDEF、运行时流程实例表ACT_RU_EXECUTION、任务表ACT_RU_TASK、历史表ACT_HI_*等。如果你用的是MySQL建议使用8.0以上版本并且把表引擎设为InnoDB因为Activiti的很多查询语句有事务依赖MyISAM不支持行级锁高并发下会出现死锁。配置数据源和自动建表策略spring: datasource: url: jdbc:mysql://localhost:3306/activiti_db?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/ShanghainullCatalogMeansCurrenttrue username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver activiti: database-schema-update: true db-history-used: true history-level: full这里有两个参数必须解释清楚。database-schema-update设为true表示当引擎启动时如果发现缺少ACT_表就自动创建开发环境方便但生产环境建议改为false由DBA预先执行官方SQL脚本建表避免应用账户拥有过大的DDL权限引发安全问题。history-level设为full表示记录所有历史信息包括流程变量、表单字段、审批意见如果业务需要查询“某某人处理过哪些工单”audit级别是不够的必须用full。提示如果把database-schema-update设成false启动报“表不存在”可以先检查MySQL连接串里的nullCatalogMeansCurrenttrue参数。不加这个参数时Activiti在部分MySQL版本下会去查information_schema里其他库的同名表导致明明连对了库却找不到表的怪问题。2.3 IDEA里Activiti插件的离线安装与BPMN设计你会在网上看到很多关于IDEA里Activiti插件安装的教程大多要求在线搜索“actiBPM”插件。但IDEA版本升级后在线插件市场经常搜不到或者插件与当前IDEA版本不兼容这时只能走离线安装的路线。我用的办法如下到JetBrains插件仓库或GitHub上的actiBPM项目Release页面下载对应IDEA版本的zip包。IDEA菜单选择File - Settings - Plugins点击右上角的齿轮图标选择Install Plugin from Disk。选中下载的zip包重启IDEA。在resources目录的processes文件夹下右键选择New - BPMN File即可创建.bpmn文件。需要注意的是actiBPM插件的维护时间比较早新版本IDEA2022可能会出现界面空白或图标不显示的问题。如果只是画流程图也可以不依赖IDEA插件直接用在线BPMN设计器或者用Activiti官方提供的Activiti Modeler基于Web。我个人流程是流程图在模型设计器里画好导出BPMN XML放到src/main/resources/processes目录IDEA只负责查看代码和部署。3. 设计一份可落地的请假流程BPMN文件里最容易被忽略的关键点3.1 节点类型与连线从开始事件到结束事件的最短认知路径BPMN 2.0规范很庞大但实际开发中高频节点就那几种。我以最经典的“员工请假”流程为例说明每个节点的真实作用和配置要点。这份流程图涉及的节点包括开始事件StartEvent流程的触发点。通常配一个activiti:initiator扩展属性记录发起人是谁。用户任务UserTask人工审批节点。必须设置activiti:assignee或activiti:candidateUsers/activiti:candidateGroups否则任务创建后没人能查到、没人能处理。排他网关ExclusiveGateway按条件选择唯一分支。结束事件EndEvent流程终止。一份最简单的请假流程XML关键片段bpmn2:process idleaveProcess name请假流程 isExecutabletrue bpmn2:startEvent idstartEvent name开始 activiti:initiatorstarter/ bpmn2:userTask idmanagerTask name部门经理审批 activiti:assignee${applyUserId}/ bpmn2:exclusiveGateway idgateway1 name请假天数判断/ bpmn2:sequenceFlow idflow1 sourceRefstartEvent targetRefmanagerTask/ bpmn2:sequenceFlow idflow2 sourceRefmanagerTask targetRefgateway1/ bpmn2:sequenceFlow idflow3 sourceRefgateway1 targetRefendEvent bpmn2:conditionExpression xsi:typebpmn2:tFormalExpression ${leaveDays lt; 3} /bpmn2:conditionExpression /bpmn2:sequenceFlow /bpmn2:process这里有一个大坑${leaveDays 3}在XML里不能直接写必须转义成lt;。很多第一次接触BPMN的人在这里卡住流程部署成功但一执行到网关就报表达式解析错误其实问题就出在这个特殊字符上。3.2 排他网关与并行网关分支逻辑的正确打开方式排他网关ExclusiveGateway适合“多选一”的场景引擎从头到尾遍历出口连线遇到第一个表达式为true的分支就走那条线。如果所有分支都不满足条件流程会抛出异常——我强烈建议在排他网关最后一条出口连线上设置默认分支不配表达式这样即使所有条件都未命中也能兜底走默认路径避免流程卡死。并行网关ParallelGateway适合“会签”场景它不判断条件纯粹同步并发和汇聚。比如员工请假超过7天需要部门经理和人事总监同时审批就可以在两条并行分支上分别挂一个UserTask等两条分支的任务都完成才继续往后走。使用者要注意并行网关的多实例配置bpmn2:userTask idmultTask name会签审批 activiti:assignee${assignee} bpmn2:multiInstanceLoopCharacteristics isSequentialfalse activiti:collection${assigneeList} activiti:elementVariableassignee /bpmn2:multiInstanceLoopCharacteristics /bpmn2:userTask这个多实例节点的含义是从流程变量assigneeList一个List类型变量里取每一个元素依次或并行给每个assignee生成一个审批任务。isSequential设为false表示并行所有人同时收到待办设为true表示顺序审批第一个人处理完才轮到下一个人。3.3 流程图设计时的三个业务侧注意事项第一事件监听节点BoundaryEvent尽量少用它会让流程时序变复杂。超时自动审批这类需求优先考虑在业务代码里通过定时任务扫描ACT_RU_TASK的CREATE_TIME_字段实现而不是在BPMN里画定时边界事件。除非流程引擎重启后定时事件能可靠恢复否则用扫描任务更可控。第二子流程SubProcess虽然好但不要嵌套超过两层。子流程让主流程简洁但问题是排错时很难一眼看出当前流程到底卡在哪个子流程的哪个节点。我的习惯是流程节点超过15个就拆子流程超过两层就认真考虑是不是设计过度了。第三所有人工节点建议都配上activiti:description描述字段说明这个审批节点的审批要点是什么。这个字段会出现在任务详情里对发起人友好也给后续做审批页面的“待办提示”提供了现成数据。4. 把设计好的BPMN流程真正集成到Spring Boot应用里4.1 三种部署方式classpath自动部署、字符串部署、RepositoryService部署Activiti流程集成到Spring Boot应用很多人问得最多的就是“我画好的bpmn文件到底怎么放、怎么让引擎认识它”。其实有三种方式分别适用于不同场景。第一种classpath自动部署。只要把.bpmn或.bpmn20.xml文件放到src/main/resources/processes目录下应用启动时activiti-spring-boot-starter会自动扫描并部署所有未部署的流程定义。每个文件会被分配一个deploymentId和processDefinitionKey即XML里process节点的id属性后面启动流程实例时就用这个processDefinitionKey。第二种通过我们熟悉的RepositoryService手动部署。这种方式适合流程文件存放在数据库、OSS或配置中心不随应用包发布的场景。核心代码Autowired private RepositoryService repositoryService; public void deployProcess(InputStream inputStream, String processName) { Deployment deployment repositoryService.createDeployment() .addInputStream(processName, inputStream) .name(processName) .deploy(); ProcessDefinition processDefinition repositoryService.createProcessDefinitionQuery() .deploymentId(deployment.getId()) .singleResult(); log.info(流程部署成功: {}, processDefinition.getKey()); }第三种直接传XML字符串部署。适合在管理后台在线编辑流程模板、保存并新版本的场景。本质和第二种一样只是把inputStream换成new ByteArrayInputStream(xmlString.getBytes(StandardCharsets.UTF_8))。4.2 流程部署版本机制为什么修改BPMN必须“发新版本”Activiti的流程定义天然支持多版本共存。每次部署同一个processDefinitionKey的流程都会生成一个新的版本号新版本自动覆盖旧版本成为默认版本。旧版本数据仍然保留在ACT_RE_PROCDEF表里已启动的流程实例继续按旧版本流程流转未启动的新实例使用最新版本。这个机制在实际项目里极其重要。它意味着你可以平滑升级流程模板而不会让正在流转中的审批中断。但也要注意如果你修改了旧版本流程的某个任务处理逻辑比如审批人表达式变了已经走到那个节点的老流程实例依然会用旧版本的表达式。如果业务要求老流程也应用新规则只能通过迁移脚本更新ACT_RU_EXECUTION里的流程变量或给旧版本流程实例做特殊处理。生产环境一定要让业务方理解这个行为不然上线容易背锅。提示自动部署默认会部署所有新增的BPMN文件但如果你只想让指定的流程文件自动部署可以在application.yml里配置spring.activiti.process-definition-location-prefix精确指定扫描路径。生产环境我建议关闭全量自动部署改为手动调用部署接口避免测试流程文件误发到生产环境。4.3 启动流程实例关联业务主键的最佳实践启动流程实例时最容易被忽略的是业务与流程的关联。绝对不要在流程表里完全脱离业务数据只靠流程实例ID去反查业务单号那样排查问题会非常痛苦。我采用的方式是在启动流程实例时把业务单号放进流程业务键businessKey并把发起人、业务关键参数写入流程变量。Autowired private RuntimeService runtimeService; public String startLeaveProcess(String applyUserId, String businessKey, int leaveDays) { MapString, Object variables new HashMap(); variables.put(applyUserId, applyUserId); variables.put(leaveDays, leaveDays); ProcessInstance processInstance runtimeService.startProcessInstanceByKey( leaveProcess, businessKey, variables); return processInstance.getId(); }这里的businessKey就存业务系统的请假单号比如LEAVE20250101001。之后不管是做流程跟踪页面还是出问题要反查“这个业务单号走到哪个节点了”都可以通过runtimeService.createProcessInstanceQuery().processInstanceBusinessKey(LEAVE20250101001).singleResult()一步查到。4.4 查询并处理任务待办列表的SQL会产生怎样的性能影响任务处理是用户面对流程时的主要操作方式包括查询我的待办、处理任务、填写审批意见、跳转流程等。查询某个用户当前的待办任务Autowired private TaskService taskService; public ListTask getTodoTasks(String userId) { return taskService.createTaskQuery() .taskAssignee(userId) .orderByTaskCreateTime() .desc() .list(); }如果是候选人任务candidateUsers或candidateGroups需要先调用taskService.claim(taskId, userId)认领任务把任务变成自己的待办之后才能处理。如果不做claim所有候选人都能在列表里看到这个任务谁先认领谁处理。这也是很多团队设计“抢单”场景的底层机制。完成任务并记录审批意见public void completeTask(String taskId, String userId, String comment, boolean approved) { taskService.addComment(taskId, null, comment); MapString, Object variables new HashMap(); variables.put(approved, approved); taskService.complete(taskId, variables); }这里面的细节是taskService.addComment会把意见写入ACT_HI_COMMENT表这个表在历史详情页里可以直接查询。审批结果approved作为流程变量传入后面的排他网关就能用${approved true}或${!approved}这样的表达式自动决定流程走向。大批量待办查询要注意性能。ACT_RU_TASK表是运行时表数据不会自动清理如果流程实例长期不结束表会越来越大。任务查询默认走taskAssignee字段索引但如果你频繁使用taskCandidateUser这类带权限的查询建议确认ACT_RU_IDENTITYLINK表上的索引是否建立否则用户量大之后查询会相当吃力。5. 核心Service API的配合逻辑一条审批链路的前世今生5.1 RepositoryService、RuntimeService、TaskService、HistoryService各管什么Activiti的核心服务访问接口有不少实际开发中高频使用的就四个RepositoryService负责流程定义与部署的增删改查。部署流程、查询流程版本、读取BPMN模型都用它。RuntimeService负责流程实例的运行时管理。启动流程、触发信号事件、删除流程实例、查询实例状态都靠它。TaskService负责人工任务的创建、查询、认领、完成、设置代理人、添加意见等一切任务操作。HistoryService负责查询历史数据包括已完成的流程实例列表、历史活动节点、历史审批记录等。这四个服务的协作关系可以类比成一套完整的工单跟踪体系RepositoryService是产品说明书管理库RuntimeService是正在执行的任务控制中心TaskService是每个人手头的待办便签HistoryService是事后审计档案室。业务代码里要查询“某人累计提交了多少条审批”走HistoryService而不是RuntimeService因为已办结的流程实例在运行时表里是查不到的。5.2 审批通过/驳回/撤销的代码级实现业务上最核心的三个操作是审批通过、驳回到上一步、发起人撤销申请。审批通过就是taskService.complete(taskId, variables)不用多说。驳回到上一步有两种实现思路。一种是直接帮用户跳转到目标节点代码复杂、易错。我更推荐的是按节点标识来驳回到任意节点public void rejectToTarget(String taskId, String targetTaskKey) { Task task taskService.createTaskQuery().taskId(taskId).singleResult(); runtimeService.createChangeActivityStateBuilder() .processInstanceId(task.getProcessInstanceId()) .moveActivityIdTo(task.getTaskDefinitionKey(), targetTaskKey) .changeState(); }发起人撤销申请最简单的方式是直接删除流程实例public void cancelProcess(String processInstanceId, String reason) { runtimeService.deleteProcessInstance(processInstanceId, reason); historyService.deleteHistoricProcessInstance(processInstanceId); }这里有一个细节值得注意如果流程实例还没有任何任务比如在等待信号状态deleteProcessInstance也会生效但如果你用了子流程一个主流程实例被删除时子流程实例默认不会自动删需要手动遍历ACT_RU_EXECUTION的子实例逐条删除。生产建议统一封装一个递归删除工具类别在业务代码里裸调API。5.3 流程引擎执行到一半卡住了怎么定位流程卡住是排障高频问题。一般思路是三步走通过runtimeService.createProcessInstanceQuery().processInstanceId(processInstanceId).singleResult()确认实例是否还在运行、当前活动节点是哪个。查询当前活动节点采用public ListString getCurrentActivityIds(String processInstanceId) { return runtimeService.getActiveActivityIds(processInstanceId); }拿到活动节点ID后去XML里反查对应节点最常见的卡住原因有三个Assignee表达式解析失败、排他网关条件没命中、用户任务没有分配处理人。如果是条件表达式解析失败日志里会直接抛出表达式异常并伴随流程实例进入错误状态。如果是处理人分配问题任务其实已经创建只是assignee字段为null所有候选人都看不到。这时可以临时用taskService.setAssignee(taskId, userId)手动指定一个处理人先让流程动起来再回头修BPMN的表达式配置。6. 四层架构下的代码落位Activiti不放Controller层也不塞进Entity层6.2 代码结构如何组织repository/service/facade分层设计Spring Boot的四层架构通常指Controller或Web层、Service层、Repository层或Mapper层、基础设施层。Activiti的代码落位要遵守一个原则凡是涉及引擎API的调用统一收敛到一个独立的activiti子包或workflow模块里不让引擎API渗透到业务Service层的每个角落。我建议的结构是com.example.project ├── controller // 只负责接收HTTP请求、参数校验、封装响应 ├── workflow │ ├── service // 流程服务接口暴露 startProcess、completeTask、reject、history 等方法 │ ├── service.impl // 实现类内部注入 RuntimeService、TaskService 等 │ └── converter // 流程引擎对象与业务DTO的转换器 ├── service // 业务服务层 ├── repository // 数据访问层 └── entity // 业务实体业务流程中如果需要在某个审批节点调用业务Service比如审批通过后自动创建出库单在WorkflowService的实现里注入业务Service是可以的但要注意控制事务边界。Activiti自身有事务管理如果业务Service操作数据库和流程引擎状态更新不在同一个事务里很容易出现“业务数据已提交流程实例没有推进”的不一致问题。6.3 事务一致性与异步任务一个容易翻车的整合点Spring Boot和Activiti整合后引擎操作默认参与Spring管理的事务。但有一个坑taskService.complete()触发流程向前推进时如果后面的节点里配置了JavaDelegate服务任务引擎会同步执行这个Delegate的逻辑。Delegate里如果再操作数据库整个链路共享一个事务任何一个环节抛异常整个事务回滚任务状态保持不变。这个特性本身是好事但经常被误用成性能瓶颈。如果执行链路里有耗时操作比如调用外部系统接口、发送消息通知务必要把这类操作设计成异步执行。实现方式有两种第一种在BPMN服务任务节点上用activiti:asynctruebpmn2:serviceTask idsendNotifyTask name发送通知 activiti:asynctrue activiti:delegateExpression${sendNotifyDelegate}/第二种在Delegate实现里用Async方法或者消息队列发送通知。这里要强调的是activiti:asynctrue会把待执行的Job记录到ACT_RU_JOB表引擎的AsyncExecutor定时扫描执行。如果你设成了异步但发现任务一直不执行先检查AsyncExecutor是否被正确初始化以及ACT_RU_JOB表里是否有异常数据把执行队列堵住了。6.4 用户体系对接Activiti不存用户表它只需要用户标识很多项目第一次用Activiti都有一个困惑用户的待办任务到底要往哪个用户表里查实际上Activiti并不维护业务系统的用户信息它只在ACT_RU_IDENTITYLINK和ACT_HI_TASKINST里记录用户ID字符串。这个用户ID可以是真实用户表的ID可以是工号也可以是手机号只要在调用API时保持一致即可。如果你的系统有用户离职、账号被删除的场景需要注意历史数据的完整性。用户ID删除后历史任务表里依然会保留这个ID前端做历史人员展示时需要单独关联用户服务查询姓名和头像不能指望Activiti提供这部分数据。我一般在职责上定义Activiti管“流程状态”业务系统管“用户信息”两者通过字符串ID关联。7. 生产环境巡检清单那些演示demo里从来不会暴露的问题7.1 数据库表膨胀与定时清理策略Activiti在生产环境跑几个月后ACT_RU_TASK、ACT_RU_EXECUTION、ACT_HI_ACTINST这几张表会迅速膨胀。运行时表本来应该只保留正在运行的流程实例但很多项目因为没做归档清理导致表里堆积大量历史数据查询性能直线下降。两条路线一是业务上定期关闭或删除已办结的大型流程实例通过定时任务调用runtimeService.deleteProcessInstance()清理运行时数据同时归档到自己的历史表二是调整history-level如果你不需要完整历史活动节点就不必用full级别用audit级别能显著减少ACT_HI_ACTINST的数据量。提示ACT_RU_JOB表是异步任务的待处理队列正常情况下数据量很小。如果你发现这张表数据量大大概率是有定时器事件在反复触发或者异步任务反复执行失败。排查时先看这张表里的RETRIES_字段失败次数太多的话Job会被锁定甚至被删除需要特别留意异常日志。7.2 Spring Boot Actuator安全小心把内部流程引擎信息泄露出去因为本文标题和热搜词里都有Spring Boot和Actuator我必须专门提一句很多Activiti管理端为了暴露引擎监控数据会把spring-boot-starter-actuator加进来并且把management.endpoints.web.exposure.include设成*导致/actuator端点完全暴露到公网。这是一个极其危险的操作。/actuator/health是必要的存活检查但/actuator/env、/actuator/beans、/actuator/configprops、/actuator/mappings这些端点一旦暴露攻击者可以分析应用内部结构、配置信息甚至构造进一步攻击。Spring Boot 3之后/actuator/shutdown默认关闭但还是要检查一遍把所有不需要的端点全部禁用。我生产项目的做法management: endpoints: web: exposure: include: health,info endpoint: health: show-details: never如果确实需要监控ACT_RU_*表的数据量建议自己写一个Controller只返回必要的指标而不要直接开放Actuator全部端点。7.3 流程表单的动态渲染如何在不改代码前提下调整表单字段Activiti的BPMN支持在UserTask节点上挂activiti:formKey属性配合引擎内置的FormService可以动态加载表单定义。但实际项目中我建议把“审批表单字段”作为工作流配置的一部分存到业务系统自己的配置表里而不是依赖Activiti的FormService。原因是Activiti的表单服务功能相对基础复杂的联动校验比如请假天数大于3天时城市KPI指标字段不可编辑在它那里实现很别扭。我采用的是BPMN文件里只维护“流程走向”表单定义独立存JSON配置放在公共模块里。启动流程时发起人提交的数据统一放流程变量Map每个UserTask的处理人打开页面时前端根据taskDefinitionKey加载对应的表单配置。这样做的灵活性最高表单字段增减完全不需要动流程文件和代码。7.4 部署到生产环境的最后检查清单最后一份压箱底的清单每次上线前务必逐条过database-schema-update是否已改为falsehistory-level是否按需定好。所有BPMN文件里的表达式是否做过XML转义排他网关是否预留了默认分支。不同环境的process-definition-location-prefix是否指向了正确的BPMN目录。用户任务节点的assignee表达式是否确认能正确解析到用户ID候选人组是否配置正确。Actuator端点是否只暴露了health和info所有调试端点是否已全部关闭。是否有定时清理ACT_RU_*表的任务是否有历史归档策略。是否备份了ACT_RE_*相关的流程定义数据回滚方案是否已准备好。从手写状态机到Activiti工作流引擎这个转型过程中最深的体会是工作流引擎并不仅仅是把状态字段变成一张流程图更是一种把业务流程沉淀为配置资产、把高频变更从代码中解放出来的架构思维。当你熟悉了“引擎管流转、业务管动作”这个边界之后后续的流程调整速度会快到让业务方惊叹。踩过的坑当然不少但这些东西一旦趟平项目里再复杂的审批流转也基本都能举重若轻地应对。
