同一个框架里的两种拦截器——注解驱动 vs 数据库驱动文章目录同一个框架里的两种拦截器——注解驱动 vs 数据库驱动一、同一个模式两种实现二、第二套拦截器流程任务级的环绕式拦截三、一个升级版异步分流四、两套拦截器放一起看五、为什么流程级用数据库而不是注解六、接口设计before 和 after 为什么分开七、passProcess 拦截器 vs doProxy 拦截链一个上午10点的场景八、结语一、同一个模式两种实现之前写过责任链拦截器——doProxy读注解拼链transInterceptor、logInterceptor、monitorInterceptor三个节点串成一条链。那是方法级的控制粒度是这个方法需不需要事务、日志、监控。但在同一个框架里还有另一套拦截器。它们不是面向方法而是面向流程任务节点。这套拦截器在ProcessService.passProcess里工作方式完全不同。两套拦截器放在一起看才是完整的横切关注点解决方案。二、第二套拦截器流程任务级的环绕式拦截passProcess是工作流审批通过的核心方法。每个流程节点的审核人点通过时走这个方法passProcess(taskid): ├── claim(taskid) // 拾取任务 ├── 从DB查拦截器配置 // 根据流程定义任务节点查表 ├── 循环 before 列表 → beforeTrans() // 前置拦截 ├── 保存表单数据 提交流程 // 核心业务 └── 循环 after 列表 → afterTrans() // 后置拦截核心代码// 获取任务拦截器——从数据库查task_interceptor intercptorobjthis.getinterceptor(taskid);Stringbeforeidnull,afteridnull;if(intercptorobj!null){beforeidintercptorobj.getBeforeId();// 前置拦截器ID列表afteridintercptorobj.getAfterId();// 后置拦截器ID列表}// 执行前置拦截器if(beforeid!null!.equals(beforeid)){String[]beforeidsbeforeid.split(,);for(inti0;ibeforeids.length;i){before beforeobj(before)BeanFactory.getBean(beforeids[i]);beforeobj.beforeTrans(center);}}// ... 保存表单 提交流程 ...// 执行后置拦截器if(afterid!null!.equals(afterid)){String[]afteridsafterid.split(,);for(inti0;iafterids.length;i){after afterobj(after)BeanFactory.getBean(afterids[i]);afterobj.afterTrans(center);}}这套拦截器有几个特点配置放在数据库里。task_interceptor表存储了流程定义Key、任务节点Key、前置拦截器ID列表、后置拦截器ID列表。修改一个节点要不要加拦截器改一行记录就行代码不用动。调用方式是顺序循环。不是责任链的串一串而是最简单的 for 循环——先跑完所有前置再跑业务再跑完所有后置。这样做的好处是前置之间彼此独立一个拦截器失败不会影响后续拦截器的调用。before和after是两个分离的接口。它们不是同一个接口的不同方法而是两个完全独立的接口。这意味着——同一个节点可以只配前置不配后置反之亦然。比如社会保险关系转出节点的 after 里配一个同步到税务系统但不需要前置拦截。三、一个升级版异步分流在passProcessHK里after 拦截器还做了一个精妙的分流for(inti0;iafterids.length;i){after afterobj(after)BeanFactory.getBean(afterids[i]);if(isSpecific(intercptorobj.getTaskDefKey(),afterids[i])){// 特定节点特定拦截器 → 异步线程execTax execnewexecTax(afterobj,center);newThread(exec).start();}else{// 普通情况 → 同步执行afterobj.afterTrans(center);}}这里引入了一个isSpecific判断——查询configSpecificDao表看当前节点是否配置了某个 after 拦截器的特殊处理。比如同步税务这个操作在大部分节点是同步执行流程必须等税务确认才能往下走但在某些只读节点可以异步执行后台慢慢推不影响审批人点通过。同一个拦截器同样的 after 接口在 A 节点走同步、在 B 节点走异步——这不是代码决定的是数据库里的configSpecificDao表决定的。这就是数据库驱动配置的威力拦截策略的变更不需要重新编译、不需要重启服务改一条SQL就上线。四、两套拦截器放一起看doProxy 拦截链passProcess 拦截器粒度方法级同一个类的所有方法流程任务级某个流程的某个节点配置方式注解TransLoggermonitoring数据库task_interceptor表调用模式责任链trans→log→monitor→invoke顺序循环逐个调 before/after拦截器接口统一的Interceptor.invoke()分离的before.beforeTrans()after.afterTrans()顺序控制链的拼装顺序决定执行顺序循环顺序即执行顺序变更成本改代码、编译、部署改数据库一行记录适用场景通用基础设施事务、日志、监控业务级横切数据同步、消息推送、权限检查这不是两套独立的方案而是同一个模式在不同粒度的两种表现方法级用注解因为这个方法要不要事务是框架能力跟具体业务逻辑无关流程级用数据库因为审批通过后要不要同步税务是业务能力跟具体流程设计有关五、为什么流程级用数据库而不是注解一个很自然的问题是passProcess里的拦截器为什么不像doProxy一样用注解在 ProcessService 的方法上加Before(taxSync)、After(pushMessage)不就行了吗不行。因为同一个passProcess方法处理所有流程的所有节点。审批请假、报销、资产申购、合同签批——几百个流程、几千个节点都走过同一个passProcess方法。你在方法上加Before那就是对所有流程生效做不到只在社保关系转移的审批节点触发同步税务。数据库驱动的拦截器解决了这个问题绑定的单位不是方法而是 (流程定义Key, 任务节点Key) 的组合。-- task_interceptor 表结构简化key|taskDefKey|beforeid|afterid-------------|--------------|---------------|------------social_trans|hr_approve|checkLimit|notifySMS social_trans|finance_pay|validateFund|syncTax,pushMessage leave_apply|manager_ok||notifySMS同一个passProcess执行到social_trans流程的finance_pay节点时触发validateFund前置 syncTax、pushMessage后置。执行到leave_apply流程的manager_ok节点时只触发notifySMS后置。这就是数据库配置的本质把在哪里触发什么从代码中抽出来变成数据。六、接口设计before 和 after 为什么分开doProxy 的链式拦截器只有一个Interceptor接口。passProcess 却拆成了两个publicinterfacebefore{voidbeforeTrans(DataCentercenter);}publicinterfaceafter{voidafterTrans(DataCentercenter);}为什么要分开因为前置和后置的责任边界不同。前置拦截器可以拒绝执行——比如checkLimit发现预算超了抛异常流程中止用户看到错误提示。后置拦截器不应该拒绝执行——审批已经通过了syncTax同步失败应该重试不应该让用户收到审批失败了但其实是同步税务报错这种混淆信息。更实际的是很多业务场景只需要后置不需要前置比如审批通过后发短信通知或者只需要前置不需要后置比如审批前校验数据完整性。拆成两个接口数据库里配一个字段就行不需要配了之后在代码里判断beforeId为空时跳过。七、passProcess 拦截器 vs doProxy 拦截链一个上午10点的场景假设一个社保局的审批人员在上午10点通过了某人的社保关系转移申请。doProxy 链做的事通用基础设施transInterceptor开启事务logInterceptor记录调用 passProcessinsidXXmonitorInterceptor开始计时passProcess 拦截器做的事业务流程切面before:validateTransfer→ 校验是否符合转出条件before:checkArrears→ 检查是否欠费业务保存表单、完成任务、流转到下一个节点after:syncNationalPlatform→ 同步到国家医保平台after:sendSMS→ 给申请人发已受理短信两套拦截器的分工是明确的doProxy 管的是这个代码执行得对不对——事务、日志、监控passProcess 管的是这个业务发生时要联动什么——校验、同步、通知八、结语同一个框架里有两种拦截器实现不是设计冗余是粒度需求不同。方法级需求“所有方法都需要事务”用注解因为它是编译时就确定的通用规则。流程级需求“社保转移审批通过时要同步税务”用数据库因为它是随政策变化而变化的业务规则。两套拦截器的接口设计也不同——方法级用统一的Interceptor接口做责任链流程级拆成before和after做环绕式。这不是谁更优雅的问题是每个粒度需要什么样的控制方式。最重要的是这个认知拦截器不只有一种实现方式。注解驱动的、责任链串接的、CGLIB 代理的——这些是互联网后端的主流答案。但政务系统里真正需要灵活变更的是业务流程级别的横切逻辑数据库驱动反而更合适。改一行记录就上线不需要走编译部署流程。知道什么时候该用哪种——这比会用其中任何一种都重要。