责任链模式拆解复杂业务规则：从无人敢改的函数到可维护的处理器链|transaction|代码|处理器|责任链

每个系统发展到某个阶段，都会出现一个没人愿意碰的函数。

它一开始很小：一个简单的校验、一个if语句、再来一个。需求增长，条件越加越多，函数越来越长。有人加了一行注释："改之前必须通读全文。"这个函数成了新人的"成人礼"，入职培训时就会被特别警告。

这就是复杂业务规则堆在同一个地方、没有刻意设计去约束它的后果。

责任链模式（Chain of Responsibility）存在的意义，正是阻止这种情况发生。它不用一个什么都知道、什么都做的方法，而是构建一条由专注的处理器组成的链。每个处理器只掌握一条规则，检查请求是否满足自己的规则——满足就传给下一个，不满足就在此处终止。

没有处理器知道链条有多长，也不知道前后是谁。每个处理器只做自己的事，然后决定：停在这里，还是继续往下传。

责任链模式是什么？

这是一种行为型设计模式，让请求沿着一条处理器链传递。链上的每个处理器自行决定：处理请求并终止链条，或者把请求交给下一个处理器。

这个模式在生产系统中带来三个关键价值。

第一，它把请求的发送方和接收方解耦。发起交易校验的代码并不知道最终由哪个处理器处理或拦截，它只是启动链条。

第二，每个处理器只承担单一职责。每个处理器只负责一条业务规则，规则变化时只需修改一个类，其他代码不受影响。

第三，链条可配置。添加、移除或重排处理器，都不需要改动现有处理器代码。新的合规要求变成一个新处理器插进链条，而不是在现有方法里加一个新分支。

没有责任链的交易校验长什么样？

下面这段代码展示了未使用该模式时的交易处理逻辑：

void handleTransaction(Transaction transaction) {if (transaction.isFraud) {// 拦截交易return;if (!transaction.isKycVerified) {// 拒绝交易return;if (!transaction.isAccountActive) {// 拒绝交易return;if (transaction.amount < 50000) {// 初级审批return;if (transaction.amount <= 200000) {// 中级审批return;if (transaction.amount <= 1000000) {// 经理审批return;// 高管审批}

这段代码今天能跑。明天合规团队要加信用分检查，风控团队要加速率检查——问题就来了。

两个真实场景：交易审批流与用户注册校验

交易审批流是责任链的典型应用。欺诈检测、KYC验证、账户状态、金额分级审批，每个环节都是一个独立处理器。新增一个合规要求，就是往链上插一个新节点。

用户注册校验同样适用。邮箱格式、密码强度、手机号验证、邀请码检查——每个校验规则独立成处理器，链条按顺序执行。某个规则变更，只改对应处理器，不影响其他校验逻辑。

这两个场景放在一起看，共同点很明显：业务规则数量会增长、规则之间有先后依赖、每条规则独立变化。这正是责任链模式发挥价值的地方。

什么时候该用责任链模式？

当你的业务规则符合以下特征时，值得考虑这个模式：