深入浅出责任链模式：解耦流程的优雅设计之道

深入浅出责任链模式：解耦流程的优雅设计之道

在软件开发中，我们经常会遇到这样的场景：一个请求需要经过多个对象的处理，每个对象都有机会决定处理这个请求，或者将其传递给下一个对象。比如用户提交的表单验证、请求的权限校验、日志的分级处理等。如果我们将所有处理逻辑都耦合在一起，代码会变得臃肿、难以维护，且扩展性极差。而​责任链模式​，正是为解决这类"流程化请求处理"问题而生的优雅设计方案。

今天，我们就来深入浅出地聊聊责任链模式------它是什么、核心原理是什么、如何实现，以及在实际开发中该如何灵活运用，避开那些容易踩坑的地方。

一、什么是责任链模式？

责任链模式（Chain of Responsibility Pattern）是一种行为型设计模式，其核心思想是：将多个处理对象串联成一条"链"，当一个请求发起时，请求会沿着这条链依次传递，直到链中的某个对象能够处理该请求，或者请求到达链的末端被拒绝处理。

简单来说，责任链模式就像公司里的"审批流程"：员工提交报销申请，先由部门经理审批，部门经理无权审批的大额报销，会传递给财务总监，财务总监再根据金额决定是否提交给总经理，直到有人审批通过或拒绝。每个审批者都有自己的职责范围，无需关心上一个审批者是谁、下一个审批者是谁，只需专注于自己的审批逻辑------这就是责任链模式的核心价值：​解耦请求发送者与处理者​，让处理流程更灵活、可扩展。

官方定义更严谨：为请求创建一个接收者对象的链。每个接收者都包含对另一个接收者的引用，如果一个接收者不能处理该请求，它会把请求传递给下一个接收者，直到请求被处理为止。

二、责任链模式的核心结构

责任链模式的结构并不复杂，主要包含 4 个核心角色，缺一不可，我们用"审批流程"的例子来对应理解，更易上手：

1. 抽象处理者（Abstract Handler）

定义处理请求的统一接口，同时包含一个对"下一个处理者"的引用（也就是链的连接点）。它通常是一个抽象类或接口，规定了所有具体处理者必须实现的"处理方法"和"设置下一个处理者"的方法。

比如"审批者"抽象类，会定义"审批方法"（处理请求）和"设置下一个审批者"的方法，无论部门经理、财务总监，都要继承这个抽象类，实现自己的审批逻辑。

2. 具体处理者（Concrete Handler）

实现抽象处理者的接口，负责处理自己职责范围内的请求；如果无法处理，则将请求传递给下一个处理者。每个具体处理者都有自己的"处理阈值"，超过阈值则传递请求。

比如部门经理（处理 ≤1000 元的报销）、财务总监（处理 1000-10000 元的报销）、总经理（处理 >10000 元的报销），都是具体处理者。

3. 请求对象（Request）

包含请求的具体信息，供处理者判断是否能够处理。比如报销申请中的"报销金额""报销事由"，就是请求对象的核心属性。

4. 客户端（Client）

创建具体处理者对象，构建责任链的顺序，然后将请求发送到责任链的第一个处理者，无需关心请求的具体处理过程和最终由谁处理。

比如员工提交报销申请，就是客户端行为------员工只需将申请交给第一个审批者（部门经理），无需关心后续谁来审批、审批流程如何。

三、责任链模式的实现（以 Java 为例）

光说理论太抽象，我们用"报销审批"这个最贴近实际开发的场景，实现一个简单的责任链模式，帮大家理解每一步的逻辑。

步骤 1：定义请求对象（Request）

请求对象包含报销的核心信息，这里我们简化为"报销金额"和"报销事由"：

// 报销请求对象
public class ExpenseRequest {
    // 报销金额
    private double amount;
    // 报销事由
    private String reason;

    // 构造方法、getter/setter
    public ExpenseRequest(double amount, String reason) {
        this.amount = amount;
        this.reason = reason;
    }

    public double getAmount() {
        return amount;
    }

    public String getReason() {
        return reason;
    }
}

步骤 2：定义抽象处理者（Abstract Handler）

抽象类定义统一的处理方法和下一个处理者的引用：

// 抽象审批者（抽象处理者）
public abstract class Approver {
    // 下一个审批者（链的连接点）
    protected Approver nextApprover;

    // 设置下一个审批者
    public void setNextApprover(Approver nextApprover) {
        this.nextApprover = nextApprover;
    }

    // 抽象审批方法（必须由具体审批者实现）
    public abstract void approve(ExpenseRequest request);
}

步骤 3：实现具体处理者（Concrete Handler）

分别实现部门经理、财务总监、总经理三个具体审批者，每个审批者处理自己职责范围内的请求，无法处理则传递给下一个：

// 部门经理（处理≤1000元）
public class DepartmentManager extends Approver {
    @Override
    public void approve(ExpenseRequest request) {
        if (request.getAmount() <= 1000) {
            System.out.println("部门经理审批通过：报销金额" + request.getAmount() + "元，事由：" + request.getReason());
        } else {
            // 无法处理，传递给下一个审批者
            if (nextApprover != null) {
                nextApprover.approve(request);
            } else {
                System.out.println("部门经理无法审批，且无后续审批者，审批失败");
            }
        }
    }
}

// 财务总监（处理1000-10000元）
public class FinanceDirector extends Approver {
    @Override
    public void approve(ExpenseRequest request) {
        if (request.getAmount() > 1000 && request.getAmount() <= 10000) {
            System.out.println("财务总监审批通过：报销金额" + request.getAmount() + "元，事由：" + request.getReason());
        } else {
            if (nextApprover != null) {
                nextApprover.approve(request);
            } else {
                System.out.println("财务总监无法审批，且无后续审批者，审批失败");
            }
        }
    }
}

// 总经理（处理>10000元）
public class GeneralManager extends Approver {
    @Override
    public void approve(ExpenseRequest request) {
        if (request.getAmount() > 10000) {
            System.out.println("总经理审批通过：报销金额" + request.getAmount() + "元，事由：" + request.getReason());
        } else {
            if (nextApprover != null) {
                nextApprover.approve(request);
            } else {
                System.out.println("总经理无法审批，且无后续审批者，审批失败");
            }
        }
    }
}

步骤 4：客户端测试（构建责任链并发起请求）

客户端创建具体处理者，构建责任链（部门经理 → 财务总监 → 总经理），然后发起不同金额的报销请求，测试责任链的处理逻辑：

public class Client {
    public static void main(String[] args) {
        // 1. 创建具体审批者
        Approver departmentManager = new DepartmentManager();
        Approver financeDirector = new FinanceDirector();
        Approver generalManager = new GeneralManager();

        // 2. 构建责任链：部门经理 → 财务总监 → 总经理
        departmentManager.setNextApprover(financeDirector);
        financeDirector.setNextApprover(generalManager);

        // 3. 发起不同金额的报销请求
        ExpenseRequest request1 = new ExpenseRequest(800, "办公文具采购");
        ExpenseRequest request2 = new ExpenseRequest(5000, "客户接待费用");
        ExpenseRequest request3 = new ExpenseRequest(15000, "年度团建费用");
        ExpenseRequest request4 = new ExpenseRequest(20000, "违规报销"); // 假设总经理也无法审批（实际可根据业务调整）

        // 4. 提交请求（只需交给第一个审批者）
        departmentManager.approve(request1);
        departmentManager.approve(request2);
        departmentManager.approve(request3);
        departmentManager.approve(request4);
    }
}

测试结果

部门经理审批通过：报销金额800.0元，事由：办公文具采购
财务总监审批通过：报销金额5000.0元，事由：客户接待费用
总经理审批通过：报销金额15000.0元，事由：年度团建费用
总经理无法审批，且无后续审批者，审批失败

从测试结果可以看出，不同金额的请求被正确传递到对应的处理者，实现了"请求发送者与处理者解耦"------客户端只需提交请求，无需关心谁来处理、如何处理。

四、责任链模式的两种常见形式

在实际开发中，责任链模式主要有两种实现形式，根据业务场景选择即可：

1. 纯责任链（Pure Chain）

特点：每个处理者要么完全处理请求，要么完全不处理，将请求传递给下一个处理者，不允许部分处理后再传递。比如我们上面实现的报销审批，就是纯责任链------部门经理要么审批（≤1000 元），要么传递，不会审批一部分再传递。

优势：逻辑清晰，责任明确；缺点：灵活性稍弱，无法实现"部分处理"的场景。

2. 不纯责任链（Impure Chain）

特点：处理者可以部分处理请求，然后将剩余部分传递给下一个处理者；或者处理完请求后，依然将请求传递给下一个处理者（比如日志打印：每个处理者都打印日志，然后传递请求）。

比如"请求日志 + 权限校验 + 业务处理"的流程：日志处理者打印请求信息后，将请求传递给权限校验者，权限校验通过后，再传递给业务处理者------每个处理者都做了自己的事情，且传递请求。

优势：灵活性高，适合复杂的流程处理；缺点：责任边界模糊，容易出现重复处理或遗漏处理的问题。

五、责任链模式的优缺点

任何设计模式都有其适用场景，也有其局限性，我们在使用前必须明确其优缺点，避免滥用。

优点

• 解耦请求与处理：请求发送者无需知道哪个处理者会处理请求，处理者也无需知道请求的发送者，只需专注于自己的处理逻辑，降低了耦合度。
• 流程灵活可扩展：新增处理者时，只需修改责任链的构建顺序，无需修改原有处理者和客户端代码，符合"开闭原则"。比如新增"副总"审批（处理 5000-10000 元），只需新增一个具体处理者，调整链的顺序即可。
• 责任明确：每个处理者都有自己的职责范围，便于代码维护和问题排查。
• 简化客户端逻辑：客户端只需提交请求，无需关心处理流程，减少了客户端的代码复杂度。

缺点

• 请求可能无法被处理：如果责任链的末端没有处理请求，且没有默认的"拒绝处理"逻辑，请求会被丢弃，导致异常。
• 性能损耗：请求需要沿着链依次传递，若链过长，会增加请求的处理时间，影响性能。
• 调试难度大：当请求处理出现问题时，需要沿着链逐个排查处理者，调试成本较高。

六、责任链模式的实际应用场景

责任链模式在实际开发中应用非常广泛，尤其是在"流程化处理"的场景中，以下是几个常见的应用案例，帮大家快速联想：

1. 表单验证

用户注册表单的验证逻辑：用户名非空验证 → 密码长度验证 → 手机号格式验证 → 邮箱格式验证。每个验证规则都是一个处理者，依次验证，若某一步验证失败，直接返回错误，无需继续验证；若验证通过，传递给下一个验证者。

2. 权限校验

系统接口的权限校验：游客权限 → 普通用户权限 → 管理员权限 → 超级管理员权限。请求发起时，依次校验权限，若当前权限足够处理请求，则执行接口逻辑；若不足，传递给下一个权限等级的处理者。

3. 日志分级处理

日志系统的分级处理：DEBUG 日志 →INFO 日志 →WARN 日志 →ERROR 日志。每个日志级别对应一个处理者，处理者可以打印日志、存储日志，然后将日志传递给下一个级别（不纯责任链），实现日志的多维度处理。

4. 过滤器/拦截器链

Web 开发中的过滤器（Filter）、Spring MVC 的拦截器（Interceptor），本质上都是责任链模式。请求经过多个过滤器/拦截器处理（比如编码处理、跨域处理、登录校验），每个过滤器处理完后，将请求传递给下一个，最终到达控制器。下面我们补充一个 Spring MVC 拦截器的实战案例，更直观地感受责任链模式在实际开发中的应用：

实战案例：Spring Boot 拦截器链（登录校验 + 权限校验 + 接口日志）

Spring Boot 简化了 Spring MVC 的配置，无需额外部署 web.xml，通过注解即可快速实现拦截器链，核心逻辑与责任链模式一致。我们实现一个 Spring Boot 版本的拦截器链，包含 3 个拦截器，分别实现"接口日志打印""登录校验""权限校验"，请求依次经过这 3 个拦截器，完美契合不纯责任链的特点（每个拦截器处理自身逻辑后，传递请求）。

1. 准备 Spring Boot 基础环境（依赖配置）

首先在 pom.xml 中引入 Spring Boot Web 依赖（若使用 Gradle 可对应调整），无需额外引入 Spring MVC 依赖，Spring Boot Web 已默认集成：

<!-- Spring Boot Web依赖，集成Spring MVC核心功能 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- 可选：lombok简化实体类（若不使用可忽略） -->
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency>

2. 定义拦截器（具体处理者，与 Spring MVC 一致，无需修改）

Spring Boot 中，拦截器依然需实现 HandlerInterceptor 接口，重写 preHandle（请求处理前）方法，处理完成后通过 return true 将请求传递给下一个拦截器，return false 则终止请求，核心逻辑不变：

// 1. 接口日志拦截器（打印请求信息）
@Component // Spring Boot自动扫描注入，无需额外配置
public class LogInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 处理自身逻辑：打印请求URL、请求方式、请求时间
        String url = request.getRequestURI();
        String method = request.getMethod();
        String time = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
        System.out.println("【日志拦截器】" + time + " - 请求URL=" + url + "，请求方式=" + method);
        // 传递请求给下一个拦截器（责任链传递）
        return true;
    }
}

// 2. 登录校验拦截器（校验用户是否登录）
@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 处理自身逻辑：校验请求头中的Token（简化逻辑，实际可结合JWT）
        String token = request.getHeader("token");
        if (token == null || token.isEmpty()) {
            // 未登录，终止请求，返回JSON格式错误信息
            response.setContentType("application/json;charset=UTF-8");
            response.getWriter().write("{\"code\":401,\"msg\":\"请先登录，获取有效Token\"}");
            return false;
        }
        // 已登录，传递请求给下一个拦截器
        System.out.println("【登录拦截器】登录校验通过，Token有效");
        return true;
    }
}

// 3. 权限校验拦截器（校验用户是否有接口访问权限）
@Component
public class PermissionInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 处理自身逻辑：简化为判断请求URL是否为/admin开头，且Token为管理员标识
        String url = request.getRequestURI();
        String token = request.getHeader("token");
        if (url.startsWith("/admin/") && !"admin_token_123".equals(token)) {
            // 无权限，终止请求，返回JSON格式错误信息
            response.setContentType("application/json;charset=UTF-8");
            response.getWriter().write("{\"code\":403,\"msg\":\"无管理员权限，无法访问该接口\"}");
            return false;
        }
        // 有权限，传递请求给下一个拦截器（最终到达控制器）
        System.out.println("【权限拦截器】权限校验通过，允许访问");
        return true;
    }
}

3. 配置拦截器链（Spring Boot 核心配置，简化 XML，注解驱动）

Spring Boot 无需配置 web.xml，只需创建一个配置类，实现 WebMvcConfigurer 接口，重写 addInterceptors 方法，即可构建拦截器链，指定拦截顺序（日志拦截器 → 登录拦截器 → 权限拦截器），与责任链的传递顺序一致：

@Configuration // 标识为Spring Boot配置类，自动生效
public class WebMvcConfig implements WebMvcConfigurer {

    // 自动注入三个拦截器（Spring Boot自动扫描@Component注解的Bean）
    @Autowired
    private LogInterceptor logInterceptor;
    @Autowired
    private LoginInterceptor loginInterceptor;
    @Autowired
    private PermissionInterceptor permissionInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // 构建拦截器链，顺序决定请求传递顺序（责任链的核心：串联处理者）
        registry.addInterceptor(logInterceptor) // 第一个处理者：日志拦截
                .addPathPatterns("/**") // 拦截所有请求
                .excludePathPatterns("/login"); // 排除登录接口，无需拦截

        registry.addInterceptor(loginInterceptor) // 第二个处理者：登录校验
                .addPathPatterns("/**")
                .excludePathPatterns("/login");

        registry.addInterceptor(permissionInterceptor) // 第三个处理者：权限校验
                .addPathPatterns("/**");
    }
}

4. 编写测试控制器（Spring Boot 专属，快速测试）

新增一个简单的控制器，用于测试拦截器链的处理逻辑，Spring Boot 会自动扫描 @RestController 注解的类：

@RestController // 标识为控制器，返回JSON格式数据
@RequestMapping("/")
public class TestController {

    // 登录接口（排除拦截）
    @PostMapping("/login")
    public String login() {
        // 简化逻辑：模拟登录成功，返回Token
        return "{\"code\":200,\"msg\":\"登录成功\",\"token\":\"admin_token_123\"}";
    }

    // 普通用户接口（需登录，无需管理员权限）
    @GetMapping("/user/list")
    public String userList() {
        return "{\"code\":200,\"msg\":\"普通用户列表\",\"data\":[]}";
    }

    // 管理员接口（需登录+管理员权限）
    @GetMapping("/admin/list")
    public String adminList() {
        return "{\"code\":200,\"msg\":\"管理员列表\",\"data\":[]}";
    }
}

5. 测试验证（Spring Boot 启动即可测试，无需额外部署）

启动 Spring Boot 应用（添加 @SpringBootApplication 注解的启动类），发起 4 种不同请求，测试拦截器链的责任链传递逻辑：

1. 请求 POST /login（排除拦截）：直接到达控制器，返回登录成功和 Token，无拦截器执行；
2. 请求 GET /user/list（无 Token）：日志拦截器执行 → 登录拦截器校验失败，返回 401；
3. 请求 GET /admin/list（携带普通用户 Token）：日志拦截器执行 → 登录拦截器通过 → 权限拦截器校验失败，返回 403；
4. 请求 GET /admin/list（携带管理员 Token：admin_token_123）：日志拦截器执行 → 登录拦截器通过 → 权限拦截器通过 → 到达控制器，返回管理员列表。

补充说明：Spring Boot 的拦截器链，本质是 Spring MVC 拦截器链的简化版，核心依然是责任链模式------多个拦截器串联成链，请求沿链传递，每个处理者（拦截器）专注自身逻辑，无需关心上/下一个处理者，完美实现请求与处理的解耦，且配置更简洁、开发效率更高。

我们实现一个简单的拦截器链，包含 3 个拦截器，分别实现"接口日志打印""登录校验""权限校验"，请求依次经过这 3 个拦截器，符合不纯责任链的特点（每个拦截器处理自身逻辑后，传递请求）。

1. 定义拦截器（具体处理者）

Spring MVC 的拦截器需实现 HandlerInterceptor 接口，重写 preHandle（请求处理前）方法，处理完成后通过 return true 将请求传递给下一个拦截器，return false 则终止请求。

// 1. 接口日志拦截器（打印请求信息）
@Component
public class LogInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 处理自身逻辑：打印请求URL、请求方式
        String url = request.getRequestURI();
        String method = request.getMethod();
        System.out.println("日志拦截器：请求URL=" + url + "，请求方式=" + method);
        // 传递请求给下一个拦截器
        return true;
    }
}

// 2. 登录校验拦截器（校验用户是否登录）
@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 处理自身逻辑：校验Cookie或Token
        String token = request.getHeader("token");
        if (token == null || token.isEmpty()) {
            // 未登录，终止请求，返回错误
            response.setContentType("application/json;charset=UTF-8");
            response.getWriter().write("{\"code\":401,\"msg\":\"请先登录\"}");
            return false;
        }
        // 已登录，传递请求给下一个拦截器
        System.out.println("登录拦截器：登录校验通过");
        return true;
    }
}

// 3. 权限校验拦截器（校验用户是否有接口访问权限）
@Component
public class PermissionInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 处理自身逻辑：校验用户权限（简化为判断请求URL是否为/admin开头）
        String url = request.getRequestURI();
        if (url.startsWith("/admin/") && !"admin_token".equals(request.getHeader("token"))) {
            // 无权限，终止请求，返回错误
            response.setContentType("application/json;charset=UTF-8");
            response.getWriter().write("{\"code\":403,\"msg\":\"无访问权限\"}");
            return false;
        }
        // 有权限，传递请求给下一个拦截器（最终到达控制器）
        System.out.println("权限拦截器：权限校验通过");
        return true;
    }
}

2. 配置拦截器链（构建责任链）

通过 WebMvcConfigurer 配置拦截器，指定拦截器顺序（日志拦截器 → 登录拦截器 → 权限拦截器），即责任链的传递顺序：

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Autowired
    private LogInterceptor logInterceptor;
    @Autowired
    private LoginInterceptor loginInterceptor;
    @Autowired
    private PermissionInterceptor permissionInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // 构建拦截器链，顺序决定请求传递顺序
        registry.addInterceptor(logInterceptor) // 第一个拦截器：日志
                .addPathPatterns("/**") // 拦截所有请求
                .excludePathPatterns("/login"); // 排除登录接口

        registry.addInterceptor(loginInterceptor) // 第二个拦截器：登录校验
                .addPathPatterns("/**")
                .excludePathPatterns("/login");

        registry.addInterceptor(permissionInterceptor) // 第三个拦截器：权限校验
                .addPathPatterns("/**");
    }
}

3. 测试验证（客户端发起请求）

发起 3 种不同请求，测试拦截器链的处理逻辑：

1. 请求 /login（排除拦截）：直接到达控制器，无拦截器执行；
2. 请求 /user/list（携带无效 token）：日志拦截器执行 → 登录拦截器校验失败，返回 401；
3. 请求 /admin/list（携带普通用户 token）：日志拦截器执行 → 登录拦截器通过 → 权限拦截器校验失败，返回 403；
4. 请求 /admin/list（携带 admin_token）：日志拦截器执行 → 登录拦截器通过 → 权限拦截器通过 → 到达控制器。

测试结果对应拦截器链的传递逻辑，完美体现了责任链模式的核心：请求沿链传递，每个处理者（拦截器）专注自身逻辑，无需关心上/下一个处理者，实现了解耦。

5. 异常处理链

系统的异常处理逻辑：自定义异常 → 运行时异常 →IO 异常 →Exception 异常。每个异常处理者处理对应类型的异常，若无法处理，传递给下一个处理者，最终实现全局异常的统一处理。

七、使用责任链模式的注意事项

为了避免踩坑，我们在使用责任链模式时，需要注意以下 3 点：

1. 控制责任链的长度

链过长会导致性能损耗和调试困难，建议根据业务场景合理控制处理者的数量，一般不超过 5 个。若确实需要多个处理者，可以考虑拆分责任链，或使用其他设计模式（如组合模式）优化。

2. 明确链的末端处理逻辑

必须在责任链的末端设置"默认处理者"，用于处理所有无法被前面处理者处理的请求，避免请求被丢弃。比如报销审批中，总经理无法审批的请求，需要返回"审批失败"的提示。

3. 避免循环依赖

构建责任链时，要避免出现"处理者 A→ 处理者 B→ 处理者 A"的循环依赖，否则会导致请求陷入死循环，耗尽系统资源。

八、总结

责任链模式的核心价值，在于​解耦请求发送者与处理者​，让流程化的请求处理更灵活、可扩展。它通过将处理者串联成链，让请求自动传递，每个处理者专注于自己的职责，从而简化代码逻辑，提高代码的可维护性。

但我们也要注意，责任链模式并非万能的，它适合"多个对象处理同一请求，且处理逻辑可拆分"的场景。在实际开发中，我们需要结合业务需求，判断是否使用责任链模式，同时控制链的长度、明确末端处理逻辑，避免滥用导致的性能问题和调试困难。

最后，记住一句话：设计模式的本质是"解决特定问题的优雅方案"，没有最好的设计模式，只有最适合当前场景的设计模式。希望这篇博客能帮你真正理解责任链模式，在实际开发中灵活运用它，写出更优雅、更可维护的代码。

关注我的CSDN：https://blog.csdn.net/qq_30095907?spm=1011.2266.3001.5343