## 01、痛点

先看一段真实项目里最常见的代码。

一个订单提交服务，一开始只做参数校验：

```java
public Result submitOrder(Order order) {
    if (order.getSkuId() == null) {
        return Result.fail("参数错误");
    }
    // ... 创建订单
}
```

后来产品要求：用户状态异常不能下单；再后来要求库存不足不能下单；再后来风控要求高风险用户拦截。

于是代码变成：

```java
public Result submitOrder(Order order) {
    if (order.getSkuId() == null) {
        return Result.fail("参数错误");
    }
    if (userService.isInactive(order.getUserId())) {
        return Result.fail("用户状态异常");
    }
    if (!stockService.hasStock(order.getSkuId(), order.getQty())) {
        return Result.fail("库存不足");
    }
    if (riskService.isHighRisk(order)) {
        return Result.fail("风控拦截");
    }
    return orderService.create(order);
}
```

到这里，很多开发者觉得还能接受，毕竟只有四个 if。

真正的失控发生在半年后：限购校验、优惠资格校验、地址有效性校验、实名认证校验、设备指纹校验……一个 `submitOrder` 方法膨胀到几百行。

```
submitOrder
|
+-- if 参数错误
+-- if 用户状态异常
+-- if 库存不足
+-- if 风控拦截
+-- if 限购拦截
+-- if 优惠资格
+-- if 地址异常
+-- if 必须实名
```

新增一个校验，就要回老方法里加 if；调整一个校验顺序，要改核心 Service；想临时跳过某个校验，还要通过开关硬编码。

这就是设计模式真正要解决的场景：不是代码不够高级，而是变化已经开始失控。

> 锐评：如果系统里只有两个校验分支，未来也不会增加，那硬上一个责任链，不是为了扩展性，而是为了增加阅读理解难度。

## 02、是什么

设计模式不是背下来的代码模板，而是软件开发中反复出现的一类问题的成熟解法。

从工程视角，它分三层：

第一层：代码复用。相同逻辑不复制。  
第二层：隔离变化。把会变的部分和不变的部分分开。  
第三层：管理复杂度。让系统在需求不断追加时，修改半径可控。

责任链模式的核心思想是：将请求的发送者与最终处理者解耦，让多个处理者都有机会处理该请求。请求沿着链传递，每个节点可以决定：

- 自己处理，然后继续交给下一个节点；
- 自己处理完，不交给下一个节点；
- 直接不处理，交给下一个节点。

三个核心角色：

- `Handler`：定义统一处理接口；
- `ConcreteHandler`：具体处理器，负责某个单一校验或操作；
- `Client`：发起请求的一方，只需要面向链的入口，不关心链上有哪些节点。

字符画对比：

```
if/else 写法
Client -> 一堆 if 条件 -> 最终结果

责任链写法
Client -> Handler 入口
              |
              v
        ConcreteHandler A
              |
              v
        ConcreteHandler B
              |
              v
        ConcreteHandler C
              |
              v
            结果
```

责任链与 if/else 的本质差异：if/else 把“判断顺序”和“处理逻辑”绑死在同一个方法里；责任链把“顺序”和“节点”拆开，顺序可以动态调整，节点可以独立增删。

## 03、为什么

很多开发者学过责任链，但真实项目里仍然是 if/else。原因通常有三个：

误区一：先背模式，再找地方套。拿到需求先想“这里能不能用责任链”，而不是先识别变化点。  
误区二：看到 if/else 就认为必须上责任链或策略模式。其实两个稳定分支不需要任何模式。  
误区三：抽象层越多，架构越高级。实际上每一层抽象都有理解成本。

判断一个责任链是否值得引入，可以问五个问题：

1. 处理节点是否会持续增加？
2. 节点顺序是否需要动态调整？
3. 每个节点是否要求独立失败和短路？
4. 节点逻辑是否相对独立，能不能单独测试？
5. 引入链后，新人理解成本是否低于原来几百行 if/else？

可以用一个简单的公式：

```
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果未来变化成本不降低，就不该做。

> 锐评：十行代码能解决的问题，不要写成一场架构发布会。

## 04、架构

从真实开发问题出发，设计模式可以按“变化类型”分成一张地图：

```
需求变化
   |
   v
变化点识别
   |
   v
职责拆分
   |
   v
模式选择
   |
   v
接口稳定
   |
   v
实现扩展
```

针对不同变化：

- 多个实现怎么切换？ -> 策略模式
- 流程固定，部分步骤变化 -> 模板方法模式
- 多个处理节点串行、可插拔 -> 责任链模式
- 对象创建越来越复杂 -> 工厂模式
- 第三方接口长得不一样 -> 适配器模式
- 状态不同，行为不同 -> 状态模式

责任链在这个地图中的位置是：**多个处理节点，顺序执行，节点可增删，失败可短路**。

其稳定接口是 `Handler`，变化点是 `ConcreteHandler` 的具体实现和排列顺序。

在 Java / Spring 生态中，责任链思想大量存在：

- Servlet Filter 链
- Spring HandlerInterceptor
- 网关的过滤链
- 安全框架中的校验链

它们共同特点是：请求进入一个链，每个节点能决定是否放行或终止。

## 05、实战

拿“订单风控处理链”完整走一遍。

### 5.1 业务场景

订单提交前需要完成四类校验：

1. 参数校验
2. 用户状态校验
3. 库存校验
4. 风控校验

任何一个校验失败，立即返回失败，不再执行后续校验。

### 5.2 第一版代码

```java
public Result submitOrder(Order order) {
    if (order.getSkuId() == null) {
        return Result.fail("参数错误");
    }
    if (userService.isInactive(order.getUserId())) {
        return Result.fail("用户状态异常");
    }
    if (!stockService.hasStock(order.getSkuId(), order.getQty())) {
        return Result.fail("库存不足");
    }
    if (riskService.isHighRisk(order)) {
        return Result.fail("风控拦截");
    }
    return orderService.create(order);
}
```

### 5.3 代码开始失控

后来新增限购、优惠资格、地址有效性、实名认证，`submitOrder` 膨胀到 600 行。每个校验都依赖不同服务，方法成了“上帝方法”。单测要 mock 一堆服务，改一个 if 可能影响其他分支。

### 5.4 模式重构

先定义统一 `Handler` 接口：

```java
public interface OrderCheckHandler {
    CheckResult check(OrderContext context, CheckChain chain);
}
```

`CheckChain` 负责链式传递：

```java
public class CheckChain {
    private final List<OrderCheckHandler> handlers;
    private int index = 0;

    public CheckChain(List<OrderCheckHandler> handlers) {
        this.handlers = handlers;
    }

    public CheckResult proceed(OrderContext context) {
        if (index >= handlers.size()) {
            return CheckResult.ok();
        }
        OrderCheckHandler handler = handlers.get(index++);
        return handler.check(context, this);
    }
}
```

每个具体处理器只做一件事：

```java
@Component
@Order(1)
public class ParamCheckHandler implements OrderCheckHandler {
    @Override
    public CheckResult check(OrderContext context, CheckChain chain) {
        if (context.getOrder().getSkuId() == null) {
            return CheckResult.fail("参数错误");
        }
        return chain.proceed(context);
    }
}
```

```java
@Component
@Order(2)
public class UserCheckHandler implements OrderCheckHandler {
    @Override
    public CheckResult check(OrderContext context, CheckChain chain) {
        if (userService.isInactive(context.getOrder().getUserId())) {
            return CheckResult.fail("用户状态异常");
        }
        return chain.proceed(context);
    }
}
```

```java
@Component
@Order(3)
public class StockCheckHandler implements OrderCheckHandler {
    @Override
    public CheckResult check(OrderContext context, CheckChain chain) {
        if (!stockService.hasStock(context.getOrder().getSkuId(), context.getOrder().getQty())) {
            return CheckResult.fail("库存不足");
        }
        return chain.proceed(context);
    }
}
```

```java
@Component
@Order(4)
public class RiskCheckHandler implements OrderCheckHandler {
    @Override
    public CheckResult check(OrderContext context, CheckChain chain) {
        if (riskService.isHighRisk(context.getOrder())) {
            return CheckResult.fail("风控拦截");
        }
        return chain.proceed(context);
    }
}
```

Spring 自动发现并组装链：

```java
@Component
public class OrderCheckChainFactory {
    private final List<OrderCheckHandler> handlers;

    public OrderCheckChainFactory(List<OrderCheckHandler> handlers) {
        this.handlers = handlers;
    }

    public CheckResult check(OrderContext context) {
        return new CheckChain(handlers).proceed(context);
    }
}
```

调用方只需要：

```java
@Service
public class OrderService {
    private final OrderCheckChainFactory checkChainFactory;

    public Result submitOrder(Order order) {
        OrderContext context = new OrderContext(order);
        CheckResult result = checkChainFactory.check(context);
        if (!result.isSuccess()) {
            return Result.fail(result.getMessage());
        }
        return orderService.create(order);
    }
}
```

### 5.5 结构变化

重构前：

```
OrderService
   |
   +-- if 参数
   +-- if 用户
   +-- if 库存
   +-- if 风控
   +-- if ...
```

重构后：

```
OrderService
   |
   v
OrderCheckChainFactory
   |
   v
CheckChain.proceed()
   |
   +-- ParamCheckHandler
   |      |
   |      v
   +-- UserCheckHandler
   |      |
   |      v
   +-- StockCheckHandler
   |      |
   |      v
   +-- RiskCheckHandler
   |      |
   |      v
   成功/失败终止
```

新增一个限购处理器，只需要新增类，不需要改任何已有类：

```java
@Component
@Order(5)
public class PurchaseLimitCheckHandler implements OrderCheckHandler {
    @Override
    public CheckResult check(OrderContext context, CheckChain chain) {
        if (purchaseLimitService.exceedsLimit(context.getOrder())) {
            return CheckResult.fail("超过限购数量");
        }
        return chain.proceed(context);
    }
}
```

### 5.6 收益

- 新增校验不修改原逻辑，符合开闭原则。
- 每个校验职责单一，可独立单测。
- 顺序通过 `@Order` 调整，不影响业务代码。
- 失败立即 return 不调用 `chain.proceed`，实现短路终止。
- 可以在链的入口做统一日志、异常处理。

### 5.7 代价

- 类数量从 1 个变成 N 个，文件变多。
- 必须理解 `chain.proceed` 的隐式约定：成功要继续，失败不要继续。
- 调试需要穿越多个类，栈更深。
- 如果顺序管理混乱，可能难以排查。

### 5.8 什么时候不要用

- 只有 2 个稳定分支，短期不会增加。
- 每个处理逻辑强依赖前一个处理结果，出现复杂状态传递。
- 团队对责任链不熟悉，导致维护成本反升。
- 性能极敏感且链长度很大的场景，需要评估对象创建开销。

> 锐评：为了两个 if 拆出五个 Handler，不是设计，是阅读理解测试。
>
> 锐评：责任链不是消灭 if，而是让每个 if 变成独立、可组合、可替换的节点。

责任链口诀：**“不是把代码拆成很多类，而是让处理步骤可以自由组合。”**

## 06、洞见

责任链模式背后，真正值得掌握的是以下几个判断力。

洞见一：设计模式真正关注的是“变化”，不是“类”。责任链解决的是“校验步骤会持续增加、顺序会调整”这一变化。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。等你第二次、第三次修改同一个 if/else 时，再抽象也不迟。

洞见三：设计模式最重要的价值是降低修改半径。不使用责任链，新增校验要改核心 Service；使用后，新增校验只需要新增一个类。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。

洞见五：Spring 框架本身就是设计模式的大型实践。`HandlerInterceptor` 是责任链，`BeanFactory` 是工厂，`ApplicationListener` 是观察者，`JdbcTemplate` 是模板方法，AOP 是代理思想。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

设计模式学习不要从 23 种开始，先吃透 5 个高频模式：策略、工厂、模板方法、责任链、适配器。

责任链专项行动：

Day 1：找出项目里一个超过五个校验分支的 Service。  
Day 2：画出当前 if/else 树，标记哪些是校验步骤，哪些是业务步骤。  
Day 3：定义 `Handler` 接口和 `CheckChain`，先拆出两个最清晰的节点。  
Day 4：继续拆出剩余节点，用 Spring 自动注入并排序。  
Day 5：写单测，重点验证失败短路终止。  
Day 6：新增一个校验，验证不改已有代码。  
Day 7：复盘：链是否过度设计？是否有节点其实应该合并？

每次重构都要回答五个问题：

1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

## 08、小结

金句：**责任链不是把 if 拆成类，而是让每一个校验步骤拥有独立修改和组合的能力。**

真正值得学习的从来不是 23 个名字，而是看到变化、识别变化、隔离变化的能力。

如果读完这篇文章，你少写了一个 500 行 if/else，这篇文章就算没有白写。

## 09、链接与概念说明

GoF 指的是《Design Patterns: Elements of Reusable Object-Oriented Software》四位作者，这本书系统总结了 23 种经典设计模式，分为三大类：

- 创建型：关注对象如何创建，例如工厂、建造者、单例；
- 结构型：关注类与对象的组合，例如适配器、装饰器、代理；
- 行为型：关注对象之间的交互和职责分配，例如策略、模板方法、责任链、观察者。

SOLID 原则与设计模式紧密相关，尤其是开闭原则：对扩展开放，对修改关闭。责任链新增节点不改旧代码，正是开闭原则的典型体现。

推荐继续阅读：

- 《Design Patterns: Elements of Reusable Object-Oriented Software》GoF 原书；
- 《Head First Design Patterns》适合入门；
- Spring 官方文档中关于 `HandlerInterceptor`、Servlet Filter 的章节；
- Servlet 规范中 Filter Chain 的说明。

后来产品要求：用户状态异常不能下单；再后来要求库存不足不能下单；再后来风控要求高风险用户拦截。

《设计模式军体拳第14招》 责任链模式 Chain of Responsibility——让请求沿处理链逐级流转

以订单风控校验为例，讲清责任链何时用、如何从 if/else 演化到 Handler 链，以及 Spring 自动装配与终止策略。

架构师

编程语言

架构设计

后端

本文深入剖析责任链模式在订单校验场景中的实战应用，对比传统if/else代码膨胀痛点，展示如何通过Handler接口与CheckChain实现解耦、动态排序与短路终止。结合Spring生态，给出完整重构案例、适用判断公式及学习路径，帮助开发者识别变化点，提升代码可扩展性与维护效率。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第14招》 责任链模式 Chain of Responsibility——让请求沿处理链逐级流转-腾讯云开发者社区-腾讯云

《设计模式军体拳第14招》责任链模式 Chain of Responsibility——让请求沿处理链逐级流转

《设计模式军体拳第14招》责任链模式 Chain of Responsibility——让请求沿处理链逐级流转

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第14招》 责任链模式 Chain of Responsibility——让请求沿处理链逐级流转

《设计模式军体拳第14招》 责任链模式 Chain of Responsibility——让请求沿处理链逐级流转

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第14招》责任链模式 Chain of Responsibility——让请求沿处理链逐级流转

《设计模式军体拳第14招》责任链模式 Chain of Responsibility——让请求沿处理链逐级流转