大家好，我是晚安code。

假设一个场景：重构一个订单审核流程，if-else 已经叠到第 7 层。

VIP 校验、新用户、地区、风控、库存、优惠……加一个新规则，你得顺着代码往下数半天，生怕漏了哪个分支。

那天你决定换个思路，用责任链模式把这一坨判断拆成一条链（2026 年 8 月整理）。

这篇就来聊聊责任链模式：它是什么、能干什么、适合什么场景，再手把手写一个 Ja va 示例。

看完你就能判断自己手头的代码该不该用它，点个收藏，我们开始。

一、先看一段会呼吸的痛：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 里。

规则一变，这里就要动刀，改一处崩一片。

我们要做的，是把「谁能处理」从这堆判断里抽出来。

二、责任链模式是什么：一条链，谁接得住谁出手

责任链模式的核心，是把「谁能处理」的判断从调用方手里解耦出来，交给链上的处理器自己去判断。

拆开看，只有三样东西：

• 处理器（Handler）：链条上的每一个节点，本质上都带着一套判断逻辑，用来决定“这件事到底能不能由自己来接”。
• 后继引用（successor）：每个处理器都会明确知道自己的下一个节点是谁，这样一环扣一环，链式结构也就搭起来了。
• 请求传递：如果当前节点处理不了，请求就继续往后传；一旦某个节点能够处理，就在这里结束；要是整条链都接不住，最后就交给兜底逻辑。

Handler（处理器）：责任链上的每个节点，负责判断请求是否归自己管。

一个 Handler 管一件事，就像盖章的人只盖自己职权内的章。

看一张图就明白了——请求从链头进入，逐个节点问「是你的吗」：

对比上面那张 if-else 迷宫，责任链最大的不同是：调用方只认识链头，根本不需要知道后面排着谁。

链上的人可以随意增删，不影响外面。

三、责任链模式适用场景：这 3 种情况才值得上

责任链模式不是所有多重判断都适用，只有这 3 类场景才划算。

判断标准很简单：多个处理器按顺序轮番尝试、谁匹配谁接盘、顺序还经常要变——三者都占，才值得上。

• 1）审批 / 流程类：一个请求按级别逐级审核，到哪一级有权限就在哪一级停。请假、报销、发布审核都是典型。
• 2）过滤 / 拦截类：同一份数据要经过多道处理，每道只做一件事。日志按级别过滤、消息中间件、Web 过滤链都在干这个。
• 3）规则会动态增删：规则的顺序、数量经常变。今天加一条拦截规则，明天去掉一条，改链比改 if-else 安全得多。

四、动手实战：设计一个请假审批链

用一个请假审批的例子，几十行代码就能看透责任链的骨架。

规则很简单：请假 3 天以内组长批，7 天以内总监批，30 天以内总经理批，超过 30 天没人能批，走人工通道。

1. 先写抽象处理器

它是整条链的骨架，负责「判断 传递」的通用逻辑：

// 责任链模式骨架，Ja va 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);}

2. 再写具体处理器

然后写三个具体处理器，每个只管自己的额度，逻辑收敛到 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   " 天"); }}

3. 最后组装链条

最后在客户端组装链。这里最爽：调用方只碰链头，谁处理它根本不关心：

// 客户端：把请求丢进链里，不用管谁会处理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）：把可替换的算法各自封装，运行时由调用方选择用哪一套。

它和责任链最大的不同：策略一次选定，责任链逐级接力。

六、责任链模式的坑：好用，别滥用

责任链的最大代价是流程变隐式，链路一长调试就头大。

我见过同事接盘一条 9 层的责任链，断点从链头一路打到链尾，跳了十几步才定位到是哪个处理器没接住。

这种时候，图上的清爽有多舒服，debug 就有多难受。

好处也很实在：

• 规则增删不动调用方
• 职责天然单一
• 顺序可灵活调整

所以我的判断是——3 到 5 个固定顺序的处理器，责任链是优解；超过 8 层，建议先想想是不是该拆成别的结构。

另外两个小提醒：

• 记得给链条兜底，谁都不处理时要能明确返回，别让请求悄悄消失。
• 别把耗时逻辑塞进处理器，每条链都是串行调用，一个卡住全链等着。

收束

责任链模式，确实是解决 if-else 层层嵌套的一把利器。

但有个前提不能忽略：它在让调用方变得清爽的同时，也把复杂度悄悄转移到了链路本身。

说白了，表面上流程更干净了，代价却是「隐式流程」更重了。

链能不能真正好用，关键不在于拆得多漂亮，而在于这条链你是否真能控得住。

要是想再往下挖一层，不妨看看 Ja va 里的 Servlet 的 Filter 和 Spring MVC 的 HandlerInterceptor（搜：Ja va Filter 责任链），这两个都算是责任链模式在生产环境中的经典落地。

我是晚安code，持续分享编程干货。

觉得有用的话记得点赞收藏和关注。也欢迎在评论区聊聊：你手头有没有一段该拆却还没拆的 if-else？它长什么样？