大家好,我是晚安code。
假设一个场景:重构一个订单审核流程,if-else 已经叠到第 7 层:VIP 校验、新用户、地区、风控、库存、优惠……加一个新规则,你得顺着代码往下数半天,生怕漏了哪个分支。那天你决定换个思路,用责任链模式把这一坨判断拆成一条链(2026 年 8 月整理)。这篇就来聊聊责任链模式:它是什么、能干什么、适合什么场景,再手把手写一个 Java 示例。看完你就能判断自己手头的代码该不该用它,点个收藏,我们开始。
一、先看一段会呼吸的痛:if-else 泥潭
if-else 写判断逻辑,写十个不崩溃,加到三十个就开始失控。这是我项目里真实发生的事:订单审核的规则像洋葱一样一层套一层,加第一个 VIP 判断时觉得挺清爽,等第七个规则进来,读代码就像走迷宫。
// 示意:审核规则的 if-else 连环判断
public String auditOrder(Order order) {
if (order.isVip()) {
// 规则1:VIP 优先
if (order.getAmount() > 5000) {
// 规则2:大额走人工
if (isRisky(order)) {
// 规则3:风控拦截
return "拦截";
}
return "人工审核";
}
return "自动通过";
}
// 规则4、5、6、7……继续往下叠
return "自动通过";
}
责任链模式(Chain of Responsibility):一种行为型设计模式,把多个处理器串成一条链,请求从链头进入,逐个传给下一个,直到某个处理器表示「我能处理」为止。你可以把它想象成单位里的层层审批盖章:小额主管签,大额总监签,再大总经理拍板,没人批得动就走流程打回。
这个例子的问题在于:谁来处理订单,写死在了调用方这一大坨 if-else 里。规则一变,这里就要动刀,改一处崩一片。我们要做的,是把「谁能处理」从这堆判断里抽出来。

二、责任链模式是什么:一条链,谁接得住谁出手
责任链模式的核心是把「谁能处理」的判断从调用方手里解耦出来,交给链上的处理器自己去判断。
拆开看只有三样东西:
1)处理器(Handler):链上的每个节点,内部持有一个判断「我能不能处理」的逻辑。
2)后继引用(successor):每个处理器知道自己下一个是谁,形成链式结构。
3)请求传递:处理不了就往下一个传,处理得了就停在这里,谁都不处理就交给兜底。
Handler(处理器):责任链上的每个节点,负责判断请求是否归自己管。一个 Handler 管一件事,就像盖章的人只盖自己职权内的章。
看一张图就明白了——请求从链头进入,逐个节点问「是你的吗」:

对比上面那张 if-else 迷宫,责任链最大的不同:调用方只认识链头,根本不需要知道后面排着谁。链上的人可以随意增删,不影响外面。
三、责任链模式适用场景:这 3 种情况才值得上
责任链模式不是所有多重判断都适用,只有这 3 类场景才划算。判断标准很简单:多个处理器按顺序轮番尝试、谁匹配谁接盘、顺序还经常要变——三者都占,才值得上。
1)审批 / 流程类:一个请求按级别逐级审核,到哪一级有权限就在哪一级停。请假、报销、发布审核都是典型。
2)过滤 / 拦截类:同一份数据要经过多道处理,每道只做一件事。日志按级别过滤、消息中间件、Web 过滤链都在干这个。
3)规则会动态增删:规则的顺序、数量经常变。今天加一条拦截规则,明天去掉一条,改链比改 if-else 安全得多。

四、动手实战:设计一个请假审批链
用一个请假审批的例子,几十行代码就能看透责任链的骨架。规则很简单:请假 3 天以内组长批,7 天以内总监批,30 天以内总经理批,超过 30 天没人能批,走人工通道。
先写抽象处理器——它是整条链的骨架,负责「判断 + 传递」的通用逻辑:
// 责任链模式骨架,Java 17,2026 年 8 月验证
public abstract class Approver {
protected Approver next; // 后继:下一个处理器
public Approver setNext(Approver next) {
this.next = next; // 组装链条
return next;
}
public void handle(int days) {
if (canApprove(days)) {
doApprove(days); // 我能批,停在这里
} else if (next != null) {
next.handle(days); // 我批不了,往下传
} else {
System.out.println("无人能批,走人工通道");
}
}
protected abstract boolean canApprove(int days);
protected abstract void doApprove(int days);
}
然后写三个具体处理器,每个只管自己的额度,逻辑收敛到 4 行:
// 三个具体处理器:谁能批谁出手
class Leader extends Approver {
protected boolean canApprove(int d) {
return d <= 3; }
protected void doApprove(int d) {
System.out.println("组长批准:" + d + " 天"); }
}
class Director extends Approver {
protected boolean canApprove(int d) {
return d <= 7; }
protected void doApprove(int d) {
System.out.println("总监批准:" + d + " 天"); }
}
class GeneralManager extends Approver {
protected boolean canApprove(int d) {
return d <= 30; }
protected void doApprove(int d) {
System.out.println("总经理批准:" + d + " 天"); }
}
最后在客户端组装链。这里最爽:调用方只碰链头,谁处理它根本不关心:
// 客户端:把请求丢进链里,不用管谁会处理
public class Main {
public static void main(String[] args) {
Approver chain = new Leader()
.setNext(new Director())
.setNext(new GeneralManager());
chain.handle(5); // 输出:总监批准:5 天
chain.handle(20); // 输出:总经理批准:20 天
chain.handle(60); // 输出:无人能批,走人工通道
}
}
现在改需求——比如新增「研发总监可直接批 15 天」,你只需要 new 一个处理器,插进链中间,外面的调用方一行都不用动。这就是责任链模式代码示例里最值得体会的地方:改链不改调用方。
五、责任链 vs 它的「亲戚」
责任链和策略模式常被搞混,本质区别在于「谁来选、选一次还是继续传」。策略模式是调用方选一个用,责任链是链自己一个个试。
| 方案 | 谁来决定处理者 | 选一次还是继续传 | 适合场景 |
|---|---|---|---|
| if-else 连环判断 | 调用方自己写死 | 一次性定死 | 规则极少、几乎不变 |
| 策略模式 | 调用方主动选 | 一次选定,不再转移 | 算法可替换,单次决策 |
| 责任链模式 | 链上处理器依次判断 | 逐级传递,直到能处理 | 多级审批、过滤、拦截 |
策略模式(Strategy):把可替换的算法各自封装,运行时由调用方选择用哪一套。它和责任链最大的不同:策略一次选定,责任链逐级接力。
可能有人会问:责任链和策略模式到底啥区别?
一句话:策略模式是「调用方自己挑一个」,责任链是「链自己一个个试」。比如结算时选支付宝还是微信,用策略模式;而一条请求过 VIP、风控、库存三道关,用责任链。
六、责任链模式的坑:好用,别滥用
责任链的最大代价是流程变隐式,链路一长调试就头大。我见过同事接盘一条 9 层的责任链,断点从链头一路打到链尾,跳了十几步才定位到是哪个处理器没接住。这种时候,图上的清爽有多舒服,debug 就有多难受。
好处也很实在:规则增删不动调用方、职责天然单一、顺序可灵活调整。所以我的判断是——3 到 5 个固定顺序的处理器,责任链是优解;超过 8 层,建议先想想是不是该拆成别的结构。
可能有人会问:责任链比 if-else 代码量真的少了吗?
单看调用方,确实少了;但你多了一堆 Handler 类要维护。责任链的价值不在「少写几行」,而在「规则变化时只改一处」。
另外两个小提醒:一是记得给链条兜底,谁都不处理时要能明确返回,别让请求悄悄消失;二是别把耗时逻辑塞进处理器,每条链都是串行调用,一个卡住全链等着。

收束
责任链模式是消灭 if-else 连环判断的好工具,但要把「隐式流程」这个代价记在心里:它把复杂度从调用方挪到了链上,链是清爽了,前提是你能管住这条链。想继续深入,可以看看 Java 里 Servlet 的 Filter 和 Spring MVC 的 HandlerInterceptor(搜:Java Filter 责任链),都是责任链模式在生产里的经典用法。

我是晚安code,持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊:你手头有没有一段该拆却还没拆的 if-else?它长什么样?