SpringBoot+Flowable 审批候选人策略设计：十余种 Strategy + Invoker，一次讲清下一关谁审
流程画得再漂亮，下一关「没人可审」就全废。硬编码
assignee只能应付 demo；真实企业要的是：按角色、按部门负责人、按发起人自选、按表单里填的「项目经理」……正确姿势是策略模式：每个规则一个 Strategy，Invoker 统一注册、计算与部署校验。
▲ 一屏看清：Invoker 注册/分发/校验 → 四类策略（组织 · 发起人 · 表单 · 兜底）→ candidateStrategy / candidateParam / validateBpmnConfig
引言：下一关谁审，才是流程真正的难题
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
目标架构一句话：设计器写 strategy+param；运行时 Invoker 算人；部署前先校验。
一、策略枚举：把「人从哪来」编码化
BpmTaskCandidateStrategyEnum 用整型策略码区分规则，例如：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
设计器侧把 candidateStrategy / candidateParam 写入 UserTask 扩展属性；运行时再解析。
▲ 流程模型是策略配置的入口：每个审批节点选一种候选人规则，而不是写死工号
二、Strategy 接口：统一契约
public interface BpmTaskCandidateStrategy {BpmTaskCandidateStrategyEnum getStrategy();void validateParam(String param);default boolean isParamRequired() { return true; }Set<Long> calculateUsersByTask(DelegateExecution execution, String param);Set<Long> calculateUsersByActivity(BpmnModel model, String activityId,String param, Long startUserId, String processDefinitionId,Map<String, Object> processVariables);}
每个策略一个 Spring Bean，构造 BpmTaskCandidateInvoker 时注入 List<BpmTaskCandidateStrategy>，放进 strategyMap，重复策略码直接 Assert 失败——避免两个实现抢同一个码。
三、Invoker：计算链路与三道保险
运行时核心是 calculateUsersByTask：
Integer strategy = BpmnModelUtils.parseCandidateStrategy(flowElement);String param = BpmnModelUtils.parseCandidateParam(flowElement);Set<Long> userIds = getCandidateStrategy(strategy).calculateUsersByTask(execution, param);removeDisableUsers(userIds); // 去掉禁用账号if (CollUtil.isEmpty(userIds)) {// 候选人为空 → 走 ASSIGN_EMPTY 兜底策略userIds = getCandidateStrategy(ASSIGN_EMPTY).calculateUsersByTask(execution, param);}removeStartUserIfSkip(userIds, flowElement, startUserId); // 发起人跳过配置
三道保险值得抄：
@DataPermission(enable = false)：算候选人时关掉数据权限，避免「权限过滤导致找不到审批人」 - 禁用用户剔除
：账号停用不能继续占坑 - 为空兜底 / 发起人跳过
：空了走「审批人为空」配置；若配置了发起人与审批人相同时跳过，则从集合移除（只剩一人时不删，避免无人可审）
自动通过 / 自动拒绝的节点直接返回空集合，不再算人。
▲ 设计器节点配置把策略落到模型；部署前 Invoker.validateBpmnConfig 会扫所有 UserTask
四、部署前校验：宁可发不出去，也不要跑到一半卡住
userTaskList.forEach(userTask -> {// 自动通过/拒绝：跳过Integer strategy = BpmnModelUtils.parseCandidateStrategy(userTask);String param = BpmnModelUtils.parseCandidateParam(userTask);if (strategy == null) {throw exception(MODEL_DEPLOY_FAIL_TASK_CANDIDATE_NOT_CONFIG, userTask.getName());}if (candidateStrategy.isParamRequired() && StrUtil.isBlank(param)) {throw exception(MODEL_DEPLOY_FAIL_TASK_CANDIDATE_NOT_CONFIG, userTask.getName());}getCandidateStrategy(strategy).validateParam(param);});
这是产品体验关键：错配在发布时报错，而不是员工提交后卡在待办黑洞。
▲ 策略算对了，待办才会落到真人；算错了再漂亮的时间轴也救不了
五、四类策略怎么选（产品视角）
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
扩展新规则时：加枚举码 → 实现 Strategy Bean → 设计器下拉加一项。Invoker 不用改。
六、技术亮点总结
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
七、快速体验
-
打开 流程管理 → 流程模型，编辑一个简单流程。 -
点开审批节点，切换「指定角色 / 发起人自选 / 发起人部门负责人」等策略并保存发布。 -
故意清空某节点审批人配置再发布，确认被校验拦住。 -
发起业务单，到 待办 核对任务是否落到预期人。
常见问题（FAQ）
为什么算候选人要关闭数据权限？
候选人计算是「系统找谁该审」，不是「当前登录人能看哪些数据」。若带着数据权限过滤，部门负责人可能被滤掉，流程直接断。
候选人为空一定会失败吗？
不一定。会再走「审批人为空」策略（转交管理员、自动通过等，取决于配置）。兜底策略计算时不再剔除禁用用户，防止二次清空。
发起人自选和审批人自选有什么区别？
发起人自选：提交申请时选本节点审批人。审批人自选：当前节点审批时指定下一节点审批人。时机不同。
表单内用户字段策略的 param 是什么？
通常是表单字段名；运行时从流程变量里取出用户 ID 再解析。适合「项目经理」「对接人」等随单变化的角色。
新策略要改 Flowable 引擎吗？
不用。扩展属性仍是 strategy/param；新增一个实现 BpmTaskCandidateStrategy 的 Bean 即可被 Invoker 自动注册。
结语
候选人策略的本质，是把「下一关谁审」从硬编码变成可配置、可校验、可扩展的策略族。Invoker 负责注册与兜底，设计器负责把规则写进模型——流程才能在组织变动中活下去。
你们项目里审批人是写死的，还是已经策略化了？有没有踩过「部署成功但无人可审」？欢迎评论区交流。