责任链这个模式我最早接触的时候觉得它挺“绕”的。明明一个 if-else 就能搞定的事情非要搞出一串对象传来传去图什么呢后来在项目里被几个真实的业务场景反复“教育”之后才慢慢咂摸出味道来。这篇东西我就把责任链从原理到落地再到那些容易踩坑的细节一次性掰开揉碎讲清楚。1. 先搞清楚责任链到底解决了什么问题先丢一个最常见的业务场景请假审批。假设你是某个团队的小组长组员提交一条请假申请流程是这样的3天以内你批就行超过3天要部门负责人批超过7天还得更高级别的领导批而且这条链路上每个环节都有各自的校验逻辑。以前我见过不少人这么写public void approve(LeaveRequest request) { if (request.getDays() 3) { System.out.println(组长审批通过); return; } if (request.getDays() 3 request.getDays() 7) { System.out.println(部门负责人审批通过); return; } if (request.getDays() 7) { System.out.println(高级领导审批通过); return; } }这段代码在只有一个审批维度的时候看起来还挺清爽的。但是只要业务一变化马上就露馅比如请假天数不变但金额超过一定数额也要走更高审批或者新增了一个“项目总监审批”的层级再或者不同部门的审批规则还不一样。你会发现这个方法的 if-else 分支开始疯长而且每一个审批角色都得在同一个方法里不断堆代码最后变成一个谁也看不懂的“大泥球”。责任链模式做的事情就是把“请求”和“处理者”之间的强耦合拆开。它的核心思想非常朴素一群处理器排成一条链请求从链头开始挨个传递每个处理器决定两件事——自己能不能处理这个请求如果能那就处理完收工如果不能就把它丢给链上的下一个处理器。这不是什么高深的东西其实我们生活里到处都是。客服电话的语音菜单就是一条责任链“按1转售前按2转售后按0转人工留言请按3”。银行柜台的业务分流也是责任链取号、排队、窗口办理每个环节各自处理自己职责内的事处理不了就流转到下一个窗口。放到代码世界里责任链模式最核心的价值就是这三点解耦请求发送方完全不需要知道谁会处理这个请求、链上有几个节点、具体顺序是什么。动态调整加一个节点、删一个节点、调整顺序都只改配置的地方核心业务代码不用动。扩展性新的处理规则出现时新增一个 Handler 类挂上去就行符合开闭原则。2. 责任链的经典结构三种角色和一个链式流转机制责任链模式的类结构非常固定而且极其简单就三个角色。处理器抽象Handler定义了一个处理请求的方法接口同时持有下一个处理器的引用。这是整条链的骨架。具体处理器ConcreteHandler实现处理逻辑同时必须实现“处理不了就往下传”的动作。客户端Client构建整条责任链并发出请求通常就是把链头节点组装好然后把请求丢给链头。下面我用 Java 写一个完整的标准实现给大家做一个可直接运行的参考。为了让代码更直观我们做一个订单风控处理的场景一笔订单进来需要依次经过“黑名单检查”“金额风控检查”“库存锁定检查”每个检查节点都有自己独立的处理逻辑。先定义处理器抽象类/** * 抽象处理器包含处理器自身逻辑和下一个节点的引用 */ public abstract class OrderHandler { protected OrderHandler next; /** * 设置责任链的下一个处理器 */ public void setNext(OrderHandler next) { this.next next; } /** * 处理请求的模板方法 */ public void handle(OrderRequest request) { // 只有当前节点通过才会把请求传给下一个节点 if (doHandle(request) next ! null) { next.handle(request); } } /** * 每个具体处理器自己实现的处理逻辑 */ protected abstract boolean doHandle(OrderRequest request); }然后定义一个简单的请求对象public class OrderRequest { private String userId; // 用户ID private double amount; // 订单金额 private boolean inBlackList; // 是否命中黑名单 public OrderRequest(String userId, double amount, boolean inBlackList) { this.userId userId; this.amount amount; this.inBlackList inBlackList; } public String getUserId() { return userId; } public double getAmount() { return amount; } public boolean isInBlackList() { return inBlackList; } }接着实现三个具体处理器/** * 节点一黑名单检查 */ public class BlackListHandler extends OrderHandler { Override protected boolean doHandle(OrderRequest request) { if (request.isInBlackList()) { System.out.println(订单已拦截用户命中黑名单); return false; } System.out.println(黑名单检查通过); return true; } } /** * 节点二金额风控检查 */ public class RiskAmountHandler extends OrderHandler { private static final double MAX_AMOUNT 50000; Override protected boolean doHandle(OrderRequest request) { if (request.getAmount() MAX_AMOUNT) { System.out.println(订单已拦截单笔金额超过风控阈值); return false; } System.out.println(金额风控检查通过); return true; } } /** * 节点三库存锁定检查 */ public class StockLockHandler extends OrderHandler { Override protected boolean doHandle(OrderRequest request) { // 这里省略真实库存查询逻辑 System.out.println(库存锁定成功); return true; } }最后是客户端组装责任链public class Client { public static void main(String[] args) { // 1. 创建全部处理器节点 OrderHandler blackListHandler new BlackListHandler(); OrderHandler riskAmountHandler new RiskAmountHandler(); OrderHandler stockLockHandler new StockLockHandler(); // 2. 组装责任链黑名单 - 金额风控 - 库存锁定 blackListHandler.setNext(riskAmountHandler); riskAmountHandler.setNext(stockLockHandler); // 3. 发送请求只需要把请求交给链头 OrderRequest request new OrderRequest(user_001, 12000, false); blackListHandler.handle(request); } }跑一下这个示例控制台会按顺序输出黑名单检查通过 金额风控检查通过 库存锁定成功如果第二个处理器返回 false链条就会在那里中止不会继续往下走。这套写法有一个很关键的细节handle方法是一个模板方法它负责了“流转”的动作具体处理器只需要关心自己职责范围内的事情不需要关心怎么传下去、传给谁。这个设计好处很多后面讲坑的时候再细说。3. 责任链的两个变种纯责任链与不纯责任链前面例子里的责任链其实是“纯责任链”请求要么被链上某个节点完整处理要么被某个节点拒绝并终止链条上只会有一个处理器真正处理请求。但工程上并不是所有场景都适合纯责任链。我把两个变体都讲一下方便大家在实际项目中做选择。3.1 纯责任链一个请求只会被一个处理器处理纯责任链的规则很严格每个处理器要么完全处理请求要么完全不处理一旦某个节点处理了就结束请求不会穿过多个环节。典型的纯责任链就是前面说的审批流。审批人 A 如果自己能拍板就直接出结果不会再把流程往下传。还有一个典型场景是异常处理链NullPointerException-RuntimeException-Exception-ThrowableJava 的异常机制就是一条纯责任链每个 catch 块都是链上的节点谁匹配上谁处理处理完就完事。在实现上纯责任链通常用“返回处理结果”来判断是否需要流转如果用“布尔值”作为返回值true表示已处理、false表示未处理并需要流转。3.2 不纯责任链多个节点可以依次处理同一个请求不纯责任链就没有那么严格了每个节点处理完自己的部分后会把请求继续向后传整个链条上的节点会依次处理一遍每个环节都贡献自己的一部分逻辑。这种模式在企业级应用里反而更常见。因为它天然适合“拦截器”“过滤器”“中间件”这类场景请求进来之后日志拦截器记录一下再传给鉴权拦截器做校验再传给业务处理逻辑每个环节是叠加的关系而不是竞争的关系。Servlet 的 Filter 就是典型的不纯责任链。一个 HTTP 请求会依次经过字符编码过滤器、登录状态过滤器、权限过滤器、最终到达真正的业务接口每个 Filter 都在自己的职责范围内做处理然后通过filterChain.doFilter()把请求继续往下传。我们框架开发中经常说的“管道-过滤器”模式本质上也是不纯责任链思想的一种延伸。实现不纯责任链时处理器的方法返回值一般就不是“是否继续传递”了而是直接用调用链的chain.doFilter()来控制流转。抽象处理器的handle方法也不再是模板方法而是干脆把传递动作完全交给具体处理器来做可以这样设计public abstract class Filter { protected Filter next; public void setNext(Filter next) { this.next next; } /** * 具体节点处理完后如果还有下个节点就主动调用下个节点 */ public abstract void doFilter(Request request, Response response); }具体节点处理完自己的逻辑后手动判断、手动调next.doFilter()链条的“传递控制权”完全释放给每个节点自己灵活性最高。代价是每个节点都必须自己记得调下一个节点容易漏掉。小结一下什么时候用纯责任链什么时候用不纯责任链我的经验是这样的场景类型选择依据示例多个处理器是“互斥竞争”关系只要有一个命中就结束纯责任链审批流、异常匹配、客服智能分流多个处理器是“叠加串联”关系每个环节都要执行不纯责任链拦截器、过滤器、中间件、日志链路4. 责任链、装饰器、策略三个模式怎么区分学设计模式最大的困惑往往不是“这个模式怎么写”而是“这几个模式长得很像我到底该用哪个”。责任链、装饰器、策略这哥仨在很多文章里被混为一谈但实际上它们的意图完全不同。我用一个很接地气的类比来拆解。责任链就像流水线上的质检关卡。一个产品顺着流水线往前走每个质检员负责检查不同的项目第一个查外观第二个查功能第三个查包装。如果某个质检员发现问题产品直接下线终止如果没问题就传到下一个质检员那里。每个环节都是独立的且环节之间有先后顺序。装饰器就像套娃。它关注的是“给一个对象叠加增强功能”。比如给你一杯咖啡加一份奶泡再铺一层焦糖每一层装饰器都包裹着更内层的东西最终你得到的是一个增强过的复合对象。装饰器和责任链的区别在于装饰器永远在“外层包裹内层”而且所有层都会起作用不存在“某层处理完就把请求终止掉”的说法。策略就像换轮胎。同一个位置你可以在不同场景下换上不同规格的轮胎。策略模式关注的是“算法族的互相替换”客户手里握着的是一个策略接口的引用运行的时候可以动态换掉整个算法实现换完之后影响是全局的。单看定义还是有点抽象我直接用代码层面的区别来说明责任链的关键代码特征是“每个处理器持有下一个处理器的引用当前处理完主动往下抛”blackListHandler.setNext(riskAmountHandler); riskAmountHandler.setNext(stockLockHandler);装饰器的关键代码特征是“装饰者和被装饰者实现同一个接口装饰者内部持有被装饰者的引用并且在调用被装饰者方法前后附加行为”public class MilkDecorator extends CoffeeDecorator { public MilkDecorator(Coffee coffee) { super(coffee); } Override public double cost() { return super.cost() 2.5; // 在原始咖啡价格上叠加牛奶价格 } }策略的关键代码特征是“一个上下文对象持有策略接口运行时可以替换策略实现”public class ShoppingCart { private DiscountStrategy strategy; // 策略接口 public void setStrategy(DiscountStrategy strategy) { this.strategy strategy; } public double calculateTotal(double amount) { return strategy.discount(amount); } }一句话总结责任链核心是“多个处理器依次尝试谁合适谁处理”。装饰器核心是“多个增强层逐层包裹功能叠加”。策略核心是“一套算法接口多种实现按需替换”。5. 责任链在实际框架中的应用你不一定写过但一定用过责任链模式听起来像是教科书里的概念但它在真实框架里无处不在。我随便列几个大家肯定打过交道的场景你会发现原来自己天天在用只是没意识到。第一Servlet 的 Filter 链。前面提过一个 Java Web 项目里你配置多个过滤器它们就自动形成一条责任链。请求从第一个过滤器进入逐个通过所有过滤器之后才到达业务接口。顺序由配置决定每个过滤器都有机会处理请求或者提前终止。第二Spring MVC 的拦截器Interceptor。和 Filter 类似HandlerInterceptor的preHandle、postHandle、afterCompletion构成了一个典型的责任链调用过程多个拦截器配置后按顺序执行。第三日志框架的日志级别过滤。如果配置了日志级别为INFO那么DEBUG级别的日志事件就相当于在链上被拦截只有符合级别要求的日志事件才会继续输出到 Appender。第四消息中间件的消费者拦截链。很多消息框架在消费消息之前会执行一串消费者拦截器每个拦截器可以修改消息上下文或者决定是否继续消费这个机制也是责任链。第五规则引擎的多规则顺序匹配。比如优惠券系统中一个订单要依次匹配“新人券”“满减券”“品类券”优先级高的券先计算算完的订单金额再传给下一个规则匹配这也是责任链的变体。我把这些场景归纳为两个共同特征有一个或多个请求对象HTTP 请求、日志事件、消息、订单数据需要经过一系列处理节点。节点之间存在确定的先后次序并且每个节点都独立于其它节点可以被单独启停或调整位置。下次你在项目里遇到这种“一串处理器串在一起处理同一个请求”的结构大概率就是责任链模式的用武之地。6. 责任链的工程化改造从“能跑”到“好维护”很多文章讲到责任链就停在了“给出一个最小示例”这一步。但真实项目里的代码要远比这复杂如果只是照抄最小示例很快就会遇到维护痛点。我根据自己的项目经验针对工程落地做一些进阶改造建议。6.1 用构建器Builder封装链条组装原生的责任链用setNext()手动拼接节点链条一长就显得很啰嗦。而且如果某个节点没接上、链条断了排查起来也费劲。更规范的做法是引入构建器public class OrderHandlerChainBuilder { private OrderHandler head; private OrderHandler tail; public OrderHandlerChainBuilder addHandler(OrderHandler handler) { if (head null) { head handler; tail handler; } else { tail.setNext(handler); tail handler; } return this; } public OrderHandler build() { return head; } }使用的时候非常清爽OrderHandler chain new OrderHandlerChainBuilder() .addHandler(new BlackListHandler()) .addHandler(new RiskAmountHandler()) .addHandler(new StockLockHandler()) .build(); chain.handle(request);如果链条很长或者节点是动态配置的这个构建器还可以配合配置中心使用从配置中心读取节点列表和顺序然后逐个实例化处理器、构建链条。6.2 通过配置动态编排责任链更好的思路是把责任链节点的顺序、启停状态从代码里抽离出来交给配置表维护。这样产品经理调整审批流程的时候我们做的只是刷新配置而不是改代码发版。比如借助规则引擎或者配置中心定义一个节点列表[ { handler: blackListHandler, enabled: true }, { handler: riskAmountHandler, enabled: true }, { handler: stockLockHandler, enabled: false } ]程序启动时解析配置、实例化处理器、构建链路。启停某个节点甚至不需要改代码重启都不需要热加载之后重新构建链条就行。这种做法的代价是配置管理需要设计好否则配置错了一条链会全部乱掉所以要给链构建加上清晰完善的日志。6.3 为责任链做的两个关键扩展能力一个是链路追踪也就是给请求一个全局唯一的 traceId在每个处理器处理的前后都打印日志带上这个 traceId。这样一旦出了问题从第一个节点到最后一个节点的完整调用过程就一目了然定位问题非常快。另一个是异常处理策略。责任链的执行过程中某个节点抛异常了是直接中断整条链还是跳过该节点继续往后走这个决策会直接影响到整条链的行为。我的建议是如果是纯责任链的审批类业务发生了异常应当直接中断上抛如果是过滤器类的叠加式链路可以选择用 try-catch 包住单节点逻辑保证单个节点的异常不影响整条链。7. 责任链的常见栽坑清单这些坑我基本都踩过前面讲完了怎么正确地写接下来讲怎么写才不出问题。责任链的坑很多都是“代码能跑但维护的时候才发现不对劲”的类型我挑几个最典型的展开说一下。坑一处理器的顺序写死了业务改起来要命。比如审批流你一开始是“组长 - 经理 - 总监”后来业务变成“经理审批不过退回组长”或者“金额超过10万直接到总监”。如果这些顺序逻辑是硬编码在代码里的每次改动都要动核心类。解决办法就是用配置驱动能不改代码就不改代码。坑二链上某个节点处理完之后忘记调下一个节点。这在 Filter 类型的不纯责任链中尤其常见。一个过滤器写完了里面忘记调用chain.doFilter()结果请求就卡死在这个节点上。这个问题的排查也很费劲因为代码编译是没问题的运行也不报错只是请求没有任何响应。排查思路是先看是不是链断了、是不是有节点没有继续向下传递。养成习惯每个节点处理完逻辑后第一时间检查有没有把请求传给下一环。坑三责任链里的逻辑出现循环依赖。比如 A 节点的下一个是 B 节点B 节点的下一个又是 A 节点。某些配置不当的情况下可能形成死循环请求在链上转圈把系统栈耗光。构建链条之后最好有一个自检机制压测也能顺手覆盖到这个场景。坑四链上某个节点耗时偏高拖垮整体性能。责任链是串行执行的链条越长整体耗时就近似等于所有节点耗时之和。如果一个数据库查询很慢的节点挂在链上整个请求都被拖住。排查时可以用 traceId 记录每个节点的耗时定位热点节点。实在不行可以研究把部分节点异步化处理但异步化会改变责任链“串行有序”的语义需要业务允许才能做。坑五把责任链和职责过载混在一起。有时候一个节点内部的逻辑特别重本身做了好几件不相干的事这种情况下即使套用责任链包装了一层也只是把一个复杂节点拆成了多个复杂节点没有从根上解决职责划分问题。每个节点应该只有一个清晰的职责如果在写一个 Handler 的时候需要很费力地说明“这个节点负责什么”那大概率职责不够单一。坑六过度设计——一个 if-else 能解决的问题硬要上一整条链。责任链适合“处理器数量不确定、顺序不确定、未来大概率会新增”的场景。如果你的处理器只有固定的两三个而且业务也不会大变用责任链反而增加阅读成本。设计模式不是越多越好适合的才是好。8. 责任链的现代写法Java Stream 与函数式接口传统责任链要定义抽象类、一堆子类结构清晰但代码量不小。做框架设计时这种比较“正统”的写法没问题。但如果只是业务内部想快速组装一个过滤器序列用函数式接口配合 Stream 会轻量很多。用 Java 的Function和流的 forEach 实现一个微型责任链import java.util.ArrayList; import java.util.List; import java.util.function.Predicate; /** * 函数式责任链每个节点就是一个 Predicate 或 Consumer */ public class FunctionalChain { private final ListPredicateString rules new ArrayList(); public FunctionalChain addRule(PredicateString rule) { rules.add(rule); return this; } public boolean execute(String request) { for (PredicateString rule : rules) { if (!rule.test(request)) { System.out.println(规则拦截 request); return false; } } System.out.println(所有规则通过 request); return true; } public static void main(String[] args) { FunctionalChain chain new FunctionalChain(); chain.addRule(s - !s.contains(黑名单)); chain.addRule(s - s.length() 6); chain.addRule(s - s.startsWith(order_)); chain.execute(order_abc123); // 应该通过 chain.execute(abc123); // 长度不够链上第二个规则拦截 } }这种写法的优点是短、快、灵活适合一次性使用的校验场景。缺点是链路结构没有显式的“处理器类”如果规则太多、太复杂还是传统写法更好维护。另外也可以用Stream的anyMatch模拟“有一个处理器命中就终止”的语义boolean handled handlers.stream() .anyMatch(h - h.handle(request)); // 找到第一个能处理请求的节点虽然这种“函数式责任链”在日常业务里用起来很顺手但它并不是严格意义上的责任链模式——它丢失了“节点持有下一个节点引用”这个结构特征。所以我的态度是复杂业务用标准责任链简单校验用函数式链各取所长。9. 责任链模式和其它链式思维的边界管道、链式调用、Kafka责任链很容易和另外几个类似的术语混淆我在做技术评审的时候经常要跟同事对齐概念。这里把几个常见的边界捋清楚。第一责任链 vs 管道模式Pipeline。管道模式强调的是“数据经过一个管道每个阶段对数据进行转换”比如日志管道原始日志 - 解析器 - 清洗器 - 聚合器 - 输出器。这一点和“不纯责任链”非常相似。区别在于责任链的模式核心是“处理者的链式传递”管道模式的核心是“数据的流式加工”。结论是管道模式可以视作责任链的一种变体但管道模式里“每个阶段都会处理数据”是必然发生的事责任链里则可以有选择地中断。第二责任链 vs 链式调用Builder 链式。这两种东西完全不一样。链式调用只是语法层面的“连续调用”比如new Builder().addA().addB().build()。它本质是让多个方法调用能被写在一条语句里和“多个处理器串联处理请求”不是一回事。虽然责任链的构建器可以用链式调用风格来写但那只是构建过程不等于责任链本身。第三责任链 vs 消息队列MQ。消息队列里的消费者监听消息多个消费者组队消费这看起来也有点像“链条传递”但两者机制不同责任链是同步调用同一个线程内直接传递消息队列是异步解耦消息投递到队列之后由不同的消费者分别消费。在责任链里一个环节的成败直接影响后续环节在 MQ 里上游消费者挂了并不影响下游消费者的消息接收。搞清楚这些边界你在方案设计的时候就不会被术语带乱思路。10. 责任链模式的变体与框架实现从 Netty 到 Spring 的源码视角前面讲的是我们自己写责任链的实现方式。接下来解剖一下几个知名框架里的责任链实现看看工业级代码是怎么组织这条链的。Netty 的 ChannelPipeline 和 ChannelHandler。这是 Java 网络编程领域最经典的责任链实例。每个 Channel 都有一条 PipelinePipeline 上串着一组 ChannelHandler。一个入站事件从 Pipeline 头部进入被每个入站处理器依次处理后到达链路末端出站事件则反向流动。每个 ChannelHandler 处理完自己的逻辑后调用ctx.fireChannelRead(msg)把事件传给下一个节点。更有意思的是 Netty 的处理器链是支持动态“增删”的你可以在任何时刻往 Pipeline 里添加、删除、替换一个处理器。这种能力让 Netty 的数据处理链路变得极其灵活比如做协议解析时动态添加一个解密 handler、在传输完成后再把它移除。可以说 Netty 把责任链模式用到了极致。Spring 的 Interceptor 实现。Spring MVC 的HandlerExecutionChain内部维护一个HandlerInterceptor数组执行时按索引顺序调用每个拦截器的preHandle方法。如果某个拦截器的preHandle返回 false就直接短路后面的拦截器和处理器都不再执行。这正是典型的纯责任链逻辑找到第一个“拦截”的节点然后终止整个链条。MyBatis 的插件机制。MyBatis 的Interceptor通过动态代理实现了责任链多个拦截器形成一个链在 Executor、StatementHandler、ResultSetHandler 等执行方法的调用链上层层包裹。每个插件的intercept()方法可以选择在当前逻辑执行前后插入代码并通过invocation.proceed()把调用传下去。从这些框架里能总结出责任链的工业级实现规律用接口而不是抽象类做处理器抽象方便职责解耦和单元测试。链的构建和请求的处理分开构建链可以配置化、动态化。传递调用使用显式方法如fireChannelRead、proceed、doFilter而不是隐式返回值这样逻辑更透明。支持链路追踪每个节点的执行状态可以被观测。如果你要在一个比较重度的项目里落地责任链建议参考 Netty 的设计思路使用上下文对象Context传递请求处理器从上下文中读取数据、写入结果这样责任链的输入输出不会因为节点太多而搞得一团糟。我们来写一个简化版的上下文式责任链/** * 上下文对象贯穿整个责任链 */ public class ChainContext { private final String requestData; private Object result; // 还可以存 traceId、用户信息等 public ChainContext(String requestData) { this.requestData requestData; } public String getRequestData() { return requestData; } public Object getResult() { return result; } public void setResult(Object result) { this.result result; } }每个处理器统一实现一个接口public interface ContextHandler { void handle(ChainContext context, ChainInvoker invoker); }调用器负责按顺序执行链上的处理器public class ChainInvoker { private final ListContextHandler handlers; private int index 0; public ChainInvoker(ListContextHandler handlers) { this.handlers handlers; } public void invoke(ChainContext context) { if (index handlers.size()) { return; // 链执行完毕 } ContextHandler handler handlers.get(index); handler.handle(context, this); } }每个节点处理完自己职责后通过invoker.invoke(context)主动触发下一个节点public class LogHandler implements ContextHandler { Override public void handle(ChainContext context, ChainInvoker invoker) { System.out.println(日志记录 context.getRequestData()); invoker.invoke(context); // 继续向下执行 } }这种上下文式责任链的好处有两个一方面整个链路上的共享状态放在ChainContext里统一管理不会出现为了传一个参数把方法签名改得面目全非的情况另一方面链的调用顺序由ChainInvoker统一调度单个处理器只负责业务逻辑不需要关系下一个节点到底是什么。这种模式在中间件场景里基本是标配如果你的责任链会超过四个节点或者链路上需要传递很多中间数据我强烈建议直接采用这种设计。11. 一个完整的实战改造案例订单校验逻辑的重构过程理论讲得再多不如看一个完整的从“反模式”到“责任链模式”的重构过程。这里用下单接口的校验逻辑来做例子。原始的代码写在一个 service 方法里public void createOrder(OrderCreateDTO dto) { // 1. 校验用户状态 if (userService.getStatus(dto.getUserId()) ! UserStatus.ACTIVE) { throw new BizException(用户状态异常); } // 2. 校验商品库存 if (stockService.getStock(dto.getSkuId()) dto.getQuantity()) { throw new BizException(库存不足); } // 3. 校验风控规则 if (riskService.checkRisk(dto) ! RiskResult.PASS) { throw new BizException(触发风控拦截); } // 4. 校验优惠券 if (couponService.isCouponValid(dto.getCouponId(), dto.getUserId()) false) { throw new BizException(优惠券不可用); } // 5. 真实下单逻辑 orderService.insert(dto); }这段代码看起来也在做校验但它的每一步都是硬编码在方法里的。如果产品说“新用户下单不需要走风控”你要直接改这段代码如果产品说“加一个对账校验”你还要改这段代码。慢慢地这个方法的行数越来越长职责越来越杂测试也越来越难写。我把它重构为责任链模式。改造分三步。第一步抽象校验处理器接口public interface OrderValidator { void validate(OrderCreateDTO dto); }第二步把每一步抽成独立的校验器Component public class UserStatusValidator implements OrderValidator { Override public void validate(OrderCreateDTO dto) { if (userService.getStatus(dto.getUserId()) ! UserStatus.ACTIVE) { throw new BizException(用户状态异常); } } } Component public class StockValidator implements OrderValidator { Override public void validate(OrderCreateDTO dto) { if (stockService.getStock(dto.getSkuId()) dto.getQuantity()) { throw new BizException(库存不足); } } } Component public class RiskValidator implements OrderValidator { Override public void validate(OrderCreateDTO dto) { if (riskService.checkRisk(dto) ! RiskResult.PASS) { throw new BizException(触发风控拦截); } } } Component public class CouponValidator implements OrderValidator { Override public void validate(OrderCreateDTO dto) { if (!couponService.isCouponValid(dto.getCouponId(), dto.getUserId())) { throw new BizException(优惠券不可用); } } }第三步用一个验证链把所有校验器串起来Component public class OrderCreateRequestValidator { private final ListOrderValidator validators; public OrderCreateRequestValidator( UserStatusValidator userStatusValidator, StockValidator stockValidator, RiskValidator riskValidator, CouponValidator couponValidator) { validators new ArrayList(); validators.add(userStatusValidator); validators.add(stockValidator); validators.add(riskValidator); validators.add(couponValidator); } public void validate(OrderCreateDTO dto) { for (OrderValidator validator : validators) { validator.validate(dto); // 顺序执行任一校验失败会直接抛异常并终止 } } }然后在 service 里调用就非常干净public void createOrder(OrderCreateDTO dto) { requestValidator.validate(dto); orderService.insert(dto); }这个重构做完之后的效果是立竿见影的单一职责每个校验器只做一件事代码简单到几乎不需要注释。可扩展将来加校验器只需要写一个类并在列表里注一下service 方法一行都不改。可测试每个校验器都可以独立做单测不需要为了测试风控逻辑而构造一整套下单参数。顺序清晰校验顺序和业务语义一致理解成本很低。需要注意这个例子其实是无状态且抛异常即终止的所以直接用集合遍历实现就够了。如果某些场景下节点之间会传数据比如第一个节点计算出结果传给后面节点用那就用上下文式责任链。12. 什么时候不要用责任链模式虽然责任链模式很好用但我不建议为了写模式而写模式。有几个场景我是明确不会用责任链的。第一处理器数量固定且极少的场景。如果只有两三个固定校验规则直接按顺序调用即可。引入责任链模式会凭空增加类数量反而增加理解成本。设计模式的成本不只是代码量还有团队成员的认知成本。团队里如果有人不熟悉责任链看到一组 Handler 反而觉得绕。第二请求需要被所有节点处理的场景。如果每个节点必须处理请求、没有“中途终止”的语义那就不是责任链而是装饰器或者管道模式。选错模式会导致逻辑别扭比如为了能继续向后传每个节点都硬编码传递动作代码冗余还不优雅。第三处理器之间有强依赖关系的场景。如果后一个节点强依赖前一个节点的计算结果两者之间是紧密耦合的关系就不适合拆成责任链。责任链上的节点应该尽量独立节点之间只通过请求对象通信不应该互相感知内部实现。第四性能极其敏感、调用链非常长的场景。每一层链路调用都有函数调用开销虽然单次开销可以忽略不计但如果是一个高频调用方法且链上有几十个节点那么性能影响会被放大。这种场景优先选择合并节点、减少链路层级。第五团队协作时需要强约束规则的场景。责任链给了每个节点很大的自由度节点可以中断链路、可以修改请求数据、可以跳过下一个节点。这种自由在某些核心链路上是危险的。如果你的团队很难统一约定“链上节点不许擅自修改请求对象”“节点不允许跳过下一个节点”那么用责任链可能会变成一场灾难。这种情况下用更强制性的流程编排方式反而更稳。13. 责任链模式的未来演进方向最后聊一下这个模式的演进方向毕竟设计模式不是静态的它在不同时代有不同形态。现在比较热门的一个方向是把责任链模式和流式编排结合起来。传统的责任链做的是“顺序执行”但如果业务变得复杂一个请求可能经过的路径是分叉的根据请求类型走不同的链或者某条链的不同节点可以并行执行。这种情况下责任链思想仍然是基础但要配合流程编排引擎来实现编排引擎负责管理节点之间的拓扑关系、并行分支和聚合逻辑责任链则保留节点的“职责独立、可插拔”特性。另一个方向是协程化的责任链。在高并发场景下同步串行的责任链容易占用线程资源。用协程配合责任链每个节点在等待 IO 的时候让出线程控制权等数据就绪后再恢复执行能够在保留链路顺序语义的同时大幅提升吞吐。不过这个对团队的基础设施能力要求比较高一般业务场景暂时不需要牵这条线。还有一个看起来简单但很实用的演进是结合配置中心实现热更新责任链。节点列表、启停状态、顺序全部配置化配置变更后构建新的链替换旧链这在并发量可控的业务系统里是比较理想的状态。相当于把责任链从“编码期模式”升级为“运行期可编排模式”。无论演进成什么样责任链的核心思想“将请求发送者和多个接收者解耦让多个对象都有机会处理请求”不会变。理解了这个本质就算框架换了一茬又一茬你还是能快速识别出“这里应该有一条责任链”的抽象直觉。如果让我给一个最后的小建议学责任链的时候不要死记代码骨架而是先给自己的业务找一个“一串处理器串起来按顺序处理同一个请求”的场景。从你自己的场景出发去写、去重构、去体会那个“解耦”的感觉那些绕口的理论自然就懂了。