策略/命令/责任链模式：一家川菜馆的三种“传话”智慧

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

行为模式定位

晚上七点，川菜馆后厨热火朝天。客人、服务员、厨师各忙各的，谁都不需要认识谁：客人对服务员说“加个菜”，服务员在小票上写两笔，厨师瞟一眼就开火。这座餐厅之所以能在高峰期不崩溃，靠的不是心灵相通，而是每两个人之间都隔着一张“纸”——点菜单、小票、投诉单。软件世界也一样，对象之间一旦“直接认识”，改动就会像多米诺骨牌一样蔓延。

设计模式中有一类“行为型模式”，专门研究“对象之间如何协作、职责如何分配”。策略、命令、责任链，是其中最常用的三张“纸”。它们的共性一眼就能看出来：都在请求发送者（客人）与请求接收者（厨师）之间插入一层抽象，把“谁请求”和“谁来干”拆开。

耦合的根源，是发送者对接收者“知道得太多”——知道具体类名、知道方法签名、知道执行顺序。知道得越多，牵一发动全身。三个模式的目标，就是让发送者只依赖抽象的接口，从而让接收者可以自由替换、扩展、重组。

三种模式对“传话”的理解各不相同：策略说“我选一个人去干”，命令说“我把这件事记下来，晚点干、可以撤”，责任链说“我挨个问，谁行谁来”。记住这三句话，后面三节逐一展开。

就像餐厅里“点菜单”“小票”“投诉单”三张纸各有各的格式，三种模式解决问题的角度也不同，但共同点始终没变——让传话的双方不必互相认识。

策略模式解析

客人点了一道“鱼香肉丝”。后厨里，师傅扫了一眼食材：今天的肉偏老，那就多抓一下；灶上油温正好，直接爆炒。炒、蒸、少油版——三种做法，出锅都是“鱼香肉丝”。客人从头到尾只说了“要一份鱼香肉丝”，至于怎么做，是厨师的事。

这个场景就是策略模式：把“要做什么”和“怎么做”分开。软件里，算法经常有多种实现，比如排序有快排、归并、堆排序，支付有支付宝、微信、银行卡。策略模式把这些算法封装成互相独立、可以替换的“策略”，让上下文（厨师）在运行时按条件选一个。

策略模式有三个角色：策略接口定义算法合约，具体策略类各自实现一个算法，上下文持有策略引用并在需要时调用。它的直接收益是干掉一长串 if-else——新增算法只需加一个类，不改动上下文和调用方，这就是“开闭原则”：对扩展开放，对修改关闭。

点菜单上永远写着“鱼香肉丝”四个字，但今天端上来的可能是爆炒、可能是蒸菜。菜单不用改，厨师不用换，变的只是后厨里那个“策略”——这就是策略模式对客户端的承诺：接口不变，算法随便换。

命令模式解析

客人喊“服务员，退菜！”。服务员没有直接冲进后厨把锅掀了，而是掏出小票，写下“退：3号桌水煮鱼一条”，传到后厨。师傅看了小票，菜还没下锅，照办；已经下锅，按退款规则处理。整个过程，“退菜”这个请求变成了一张可以传递、可以存档、可以撤销的纸。

命令模式做的就是这件“把小票物化”的事：把一次请求封装成一个独立对象。这个对象里装着“让谁干、干什么、参数是什么”。于是，请求不再是一句飘在空中的话，而是一个可以排队、可以记录、可以反悔的实体。

命令模式有四个角色：Command 接口定义 execute 和 undo，具体命令持有接收者引用和参数，接收者真正干活，调用者只负责触发命令。因为命令是对象，我们可以把它塞进队列延迟执行、放进历史栈支持撤销重做、写成日志做审计——这些能力是普通函数调用给不了的。

小票上的每一笔，可排队、可退单、可查账。命令对象就是代码里的“小票”——把“请帮我把这件事做了”从一句话，变成一件可以放在口袋里、随时掏出来的东西。

责任链模式解析

客人对菜不满意，拍桌子要投诉。服务员先迎上去：“我帮您重做一份”；客人不接受，服务员请来领班；领班做不了主，又请店长。这个“麻烦”沿着一条看不见的链子往上走，走到哪一级，哪一级先判断“我处理得了吗”，处理不了就继续往上递。

责任链模式正是这条“投诉链”：把多个处理者串成一条链，请求从链头进入，逐个经过处理者。每个处理者自行判断能不能处理，能则处理并终止，不能则传给下一个。请求的发送者只需要面对链头，完全不知道后面还有谁。

责任链的实现核心是“后继引用”：每个处理者持有 next 指针，handle 方法先调用 canHandle 判断，处理不了就调用 next.handle。链的组装方式很灵活——可以在运行时按条件动态拼接，也可以在中间插入或摘除节点。终止条件完全由业务决定：可以“处理即止”，也可以“全部探一遍”。

客人永远不需要知道店长坐在哪间办公室，他只要对着最近的服务员喊一嗓子。责任链的价值就在这：请求者只认识第一个节点，后面有多少级、谁最终拍板，统统与你无关。

三模式对比

同一家川菜馆，三张纸各管一摊：点菜单告诉厨房“做什么菜”，小票记录“谁点了什么、要不要退”，投诉单决定“这个麻烦该谁拍板”。把三张纸混着用，后厨立刻乱成一锅粥。

软件里也一样。三个模式都解耦，但解耦的方向完全不同：策略是“选择一个算法”，命令是“封装一个请求”，责任链是“传递一个请求”。用错场景，代码不是更清晰，而是更绕。

看三个维度。解耦方向上：策略把“用哪个算法”的决策权交给上下文；命令把“何时执行、能否回滚”的控制权交给队列和历史栈；责任链把“谁该处理”的判断权下放给每个节点。扩展方式上：策略加一个类，命令加一个命令对象，责任链往链尾挂一个节点，三者都满足开闭原则。调用时序上：策略一次调用就结束，命令延迟到任意时刻、可反复调度，责任链可能经过多个节点才终止。

三张纸不能混着用：让点菜单去处理投诉，客人会被气走；让投诉单去传菜，师傅直接懵。挑对模式，餐厅才转得起来。

综合实战应用

成熟的餐厅，三张纸是协同作战的：客人点菜，点菜单（命令）排队传进后厨；后厨按食材状态选做法（策略）；一旦菜品出问题，投诉沿着服务员到店长往上走（责任链）。一套流程严丝合缝。

真实系统同样三管齐下。以 AI 平台的支付系统为例：用户下单，支付请求被封装成命令对象进入队列，按序执行、支持退款撤销；支付渠道（扫码、银行卡、余额）用策略封装，按金额和场景动态选择；风控环节用责任链串起“限额检查、欺诈识别、人工审批”，逐级拦截。

看一张协作图：下单模块生成 PayCommand 入队，队列调度器触发 execute；命令内部把渠道选择委托给策略，策略按金额选合适的支付方式；执行前，命令先经过风控链，链上任何一级拦截，命令都不执行并返回失败。三个模式各管一段，互不侵入——新增一个支付渠道，只需加一个策略类；新增一条风控规则，只需往链尾挂一个节点；新增一个退款场景，只需加一个命令。

这张协作图就是“代码川菜馆”的后厨全景：点菜单、厨师、投诉机制各司其职又互相咬合。把三个模式组合起来用，系统才能既扛得住流量，又经得起改需求。

AI 应用场景

Python 演示

"""策略 + 命令 + 责任链: AI 平台订单支付与风控演示"""from abc import ABC, abstractmethod  class PayStrategy(ABC):    """策略接口: 所有支付方式的共同契约"""     @abstractmethod    def pay(self, amount):        """执行扣款"""  class CardPay(PayStrategy):    def pay(self, amount):        print("[银行卡] 扣款 {} 元".format(amount))  class QrPay(PayStrategy):    def pay(self, amount):        print("[扫码支付] 扣款 {} 元".format(amount))  class PayCommand:    """命令对象: 把支付请求封装成可排队, 可撤销的小票"""     def __init__(self, strategy, amount):        self.strategy = strategy        self.amount = amount        self.paid = False     def execute(self):        self.strategy.pay(self.amount)        self.paid = True     def undo(self):        if self.paid:            print("[退款] 返还 {} 元".format(self.amount))            self.paid = False  class RiskHandler:    """责任链节点: 每个处理者自行判断能否处理"""     def __init__(self, name):        self.name = name        self.next = None     def set_next(self, handler):        self.next = handler        return handler     def handle(self, amount):        if self.check(amount):            print("[{}] 通过".format(self.name))            return self.next.handle(amount) if self.next else True        print("[{}] 拦截".format(self.name))        return False     def check(self, amount):        return True  class LimitHandler(RiskHandler):    def check(self, amount):        return amount <= 5000  class FraudHandler(RiskHandler):    def check(self, amount):        return amount <= 20000  if __name__ == "__main__":    cmd = PayCommand(QrPay(), 3000)    cmd.execute()     chain = LimitHandler("限额检查")    chain.set_next(FraudHandler("欺诈识别"))    print("风控结果: {}".format(chain.handle(3000)))     cmd.undo()

1. class PayStrategy(ABC):定义策略抽象接口，相当于菜单上固定的“菜名”，所有支付方式都实现它。
2. class PayCommand:命令对象，把“扫码付 3000 元”封装成一张小票，可延后执行、可撤销。
3. self.strategy = strategy命令内部持有策略引用，执行时把扣款动作委托给具体支付渠道。
4. def undo(self):撤销刚才的执行，就像服务员按小票退菜。
5. def set_next(self, handler):把责任链节点串起来，类似服务员指向领班、领班指向店长。
6. return self.next.handle(amount) if self.next else True自己处理不了就传给下一个节点，走到链尾则放行。
7. cmd = PayCommand(QrPay(), 3000)组装：命令 + 策略 + 金额，三者互不粘连。

常见误区

面试题