命令模式实战：从撤销功能到宏命令的完整设计

如果你写过撤销功能，就一定体会过这种感觉：刚开始只是一个按钮，后来变成两个、三个、十个，再后来每个按钮背后还要支持撤销、重做、宏录制……代码从几百行膨胀到几千行，最后连改一个参数都要小心翼翼。

先说清楚，我聊的是设计模式里的命令模式（Command Pattern），不是敲命令行，也不是网络设备里的模式切换命令。很多人在复习设计模式期末、或准备 Java 设计模式面试时，会把命令模式理解成“把一类操作封装成一个方法”，其实差了很远。命令模式的本质，是把“动作”本身变成一个对象，让它可以被传递、排队、记录和撤销。今天这篇就围绕这个核心，从一个真实重构案例出发，把命令模式讲透。

不管你是正在赶设计模式大作业，还是想在真实项目里落地这个模式，这篇文章都会比课本里的描述更接近实战。我会先带你看看不用命令模式时代码是怎么烂掉的，再完整写一个可运行的 Java 实现，最后聊聊和策略模式的区别，以及那些我在项目里踩过的坑。

1. 一次重构引发的思考：为什么工具栏代码会越写越烂

1.1 需求一多，按钮处理器就成了垃圾场

很多系统最开始都是一个类来处理所有用户操作。比如做一个文本编辑器，界面上有复制按钮、剪切按钮、粘贴按钮。第一版代码很简单，直接在按钮点击事件里写业务逻辑：

java复制public class EditorToolbar {
    private TextEditor editor;

    public void onCopyClick() {
        String selected = editor.getSelectedText();
        Clipboard.set(selected);
    }

    public void onCutClick() {
        String selected = editor.getSelectedText();
        Clipboard.set(selected);
        editor.deleteSelection();
    }

    public void onPasteClick() {
        String text = Clipboard.get();
        editor.insertText(text);
    }
}

这个版本没什么问题。三个按钮，三个方法，一眼就能看懂。但需求永远不会停在这里。

接下来产品经理说，工具栏要加一个“历史记录”面板，每个操作都要显示“刚才做了什么”。于是你开始在每个方法里加日志。然后又要支持撤销，复制可以不撤销，但剪切和粘贴必须能撤销。于是每个方法里的逻辑开始变复杂，参数开始变多，异常处理也开始重复。等到要支持“宏录制”——把连续几步操作录成一个新按钮时，这个类已经膨胀得没法看了。

1.2 传统写法为什么改不动：耦合、开闭原则、不可复用

很多人会把问题归咎于“方法里代码太多”，然后去做方法抽取，把每个操作拆成独立的方法。这样确实比写在按钮事件里舒服一点，但核心矛盾还在：操作的定义和操作的触发被硬绑在了一起。

这种写法有几个非常典型的问题：

• 违背开闭原则。每新增一个操作，都要打开这个类，加一个方法，再加一个 if/switch 分支或按钮绑定。类被反复修改，一不小心就影响老功能。
• UI 和业务逻辑耦合。按钮只负责被点击，但业务逻辑直接暴露在了 UI 层。换一个界面框架，所有点击方法都要跟着改。
• 无法记录动作历史。撤销的本质是“反着执行上一次的操作”，但普通方法调用不保存“上一次操作是什么”，调用完就丢了。
• 无法把多个操作组合成一个操作。宏、批量操作、事务操作，都需要“把一系列动作当作一个整体”，传统方法调用做不到。

这些痛点其实指向同一个设计方向：能不能把每一步操作包装成一个对象，让调用方只关心“执行”和“撤销”这两个动作？ 这就是命令模式出现的理由。

1.3 从需求倒推设计：命令模式就是给“操作”穿了一层外套

命令模式的设计思路非常直白：把所有操作弄成一个接口，接口里定义 execute() 方法，每个具体操作写成一个实现类。这样，按钮不直接认识“Light”或者“Editor”，它只认识一个 Command 接口。

你可以把命令对象想象成一个快递单。快递单本身不搬货，但它记录着“从哪取”“送到哪”“找谁签收”。物流中心只要按照快递单上的信息执行就行。命令对象也是这样，它不包含业务实体的全部信息，只记录“执行这个动作所需的最小信息”，通常是一个 Receiver 的引用和一个方法调用。

从需求倒推来看，命令模式能帮你做到的是：

1. 新增操作时，不用改已有类，只新增一个 Command 实现类。
2. UI 层只依赖 Command 接口，不依赖具体业务类。
3. 命令对象可以放进队列、栈、列表，天然支持撤销、重做、日志、事务。
4. 多个命令可以组合成复合命令，实现宏和批处理。

2. 命令模式的三个核心角色：Invoker、Command 和 Receiver 到底怎么配合

2.1 四个参与者的最小模型

课本上通常会说命令模式有四个角色：Client、Invoker、Command、ConcreteCommand、Receiver。但实际编码时，很多人会混淆谁创建命令、谁执行命令、谁真正干活。我更喜欢用三个“干活的人”来记：

• Receiver（接收者）：真正执行业务逻辑的对象。比如电灯、文件、数据库连接。
• Command（命令）：持有一个 Receiver 的引用，在 execute() 方法里调用 Receiver 的具体方法。
• Invoker（触发者）：只持有 Command 接口，调用 execute() 和 undo()，不关心背后是谁在干活。

还有一个 Client，也就是装配者，它负责把 Receiver 包装进 Command，再把 Command 设置到 Invoker 上。很多人把 Client 忽略了，结果所有代码都写在按钮事件里，命令模式就没发挥作用。

举个例子。家里的智能音箱是 Invoker，你说“开灯”，它不直接去按开关，而是把“开灯”这个指令交给对应的命令对象，命令对象再控制电灯这个 Receiver。中间多了一层，但这层正是灵活性的来源。

2.2 为什么命令对象里推荐持有 Receiver，而不是直接把逻辑写在 execute() 里

这是命令模式实现里最常见的分歧点。

有人觉得，命令模式太啰嗦，我直接在 ConcreteCommand 的 execute() 里写“把灯打开”，不是更简单吗？确实可以，但如果你把业务逻辑直接写在命令类里，Receiver 这个角色就丢失了。当多个命令都需要用到同一段业务逻辑时，你就需要在多个命令类里复制粘贴；当业务逻辑变化时，要改的就不是一个类，而是所有命令类。

正确做法是，业务逻辑尽量下沉到 Receiver 里。命令对象只做“转发”。比如 LightOnCommand 的 execute() 里只写 light.on()，不写“打开继电器、调整亮度、上报状态”这一堆细节。这样业务逻辑可以被多个命令复用，命令类本身也会维持得很小。

我自己的经验是：命令类越小，越容易做撤销、做日志、做序列化。 因为命令对象会被保存到栈里，甚至被传到别的线程、别的进程。如果一个命令对象里塞满了复杂逻辑，保存和传输都会变得非常沉重。

2.3 一句话记忆方式

如果考试或者面试要你十秒钟说出命令模式，你可以这么说：

命令模式把一次请求封装成一个对象，从而使你能够用不同的请求对客户进行参数化，并且支持请求的排队、记录日志以及撤销操作。

这是《设计模式》里的经典定义。但记住定义只是第一步，真正理解它，要靠完整实现一遍。

3. 一个最小可用实现：电灯遥控器、撤销栈和宏命令

3.1 最简接口定义：execute() + undo()

先定义一个命令接口。很多教学例子只定义 execute()，但我觉得最好一开始就把 undo() 加上。原因很简单：如果接口里没有 undo()，后面想加撤销功能时，你就要回头改所有命令类。而命令模式最重要的价值之一就是撤销。

java复制public interface Command {
    void execute();
    void undo();
}

注意，如果某些命令天然不支持撤销，可以在实现类里让 undo() 抛一个 UnsupportedOperationException，或者记录到日志里。不要让代码默默无闻地什么都不做，否则用户点了撤销却没有反应，排查起来很痛苦。

3.2 一个电灯遥控器的完整实现

假设我们有一个电灯类，它是最典型的 Receiver：

java复制public class Light {
    private boolean isOn = false;

    public void on() {
        isOn = true;
        System.out.println("灯开了");
    }

    public void off() {
        isOn = false;
        System.out.println("灯关了");
    }

    public boolean isOn() {
        return isOn;
    }
}

然后是两个具体命令：

java复制public class LightOnCommand implements Command {
    private Light light;

    public LightOnCommand(Light light) {
        this.light = light;
    }

    @Override
    public void execute() {
        light.on();
    }

    @Override
    public void undo() {
        light.off();
    }
}

public class LightOffCommand implements Command {
    private Light light;

    public LightOffCommand(Light light) {
        this.light = light;
    }

    @Override
    public void execute() {
        light.off();
    }

    @Override
    public void undo() {
        light.on();
    }
}

你可能会觉得两个类几乎一样，代码重复很严重。没错，如果只有灯一个 Receiver，这个设计确实显得冗余。但如果你再加一个风扇，加一个空调，加一个电视，每个设备的 on/off 命令都遵循同样的结构，新增一个设备就只需要写两个类，而不需要改遥控器。这就是开闭原则带来的收益。

再写一个最简单的遥控器：

java复制import java.util.ArrayDeque;
import java.util.Deque;

public class SimpleRemoteControl {
    private Command slot;
    private Deque<Command> undoStack = new ArrayDeque<>();

    public void setCommand(Command command) {
        this.slot = command;
    }

    public void pressButton() {
        if (slot == null) {
            return;
        }
        slot.execute();
        undoStack.push(slot);
    }

    public void pressUndo() {
        if (!undoStack.isEmpty()) {
            Command command = undoStack.pop();
            command.undo();
        }
    }
}

这个遥控器就是 Invoker。它不知道自己控制的是一盏灯还是一个空调，它只知道两个动作：按按钮、撤销。

3.3 撤销栈是怎么工作的

撤销的核心数据结构是栈。每次执行命令时，把命令对象压入栈顶。撤销时，从栈顶弹出命令，调用它的 undo()。栈是先进后出，所以操作顺序是：执行 A、执行 B、执行 C，撤销就是先撤销 C，再撤销 B，再撤销 A。这个顺序符合用户直觉，不用额外排序。

这里有一个很多初学者会忽略的细节：撤消时不能只调用 undo() 而不把命令从栈里移除。 如果只调用但不 pop，那么撤销按钮每次都会撤销同一条命令，永远回不到上一个状态。所以上面的实现里用了 pop()。

还有一个进阶问题：如果支持重做（redo）怎么办？最简单的方式是再准备一个 redo 栈。执行新命令时清空 redo 栈；撤销时把命令从 undo 栈移动到 redo 栈；重做时把命令从 redo 栈弹出并重新执行，再压回 undo 栈。这个逻辑很短，但很容易写错，建议用测试用例把“撤销-撤销-重做-新操作”这条路径固定下来。

3.4 宏命令：多个命令组成一个命令

命令模式通常和组合模式一起出现，最常见的例子就是宏命令。宏命令本身也是一个 Command，但它内部维护了一个命令列表，执行时依次调用每个子命令，撤销时逆序调用子命令的 undo()。

java复制import java.util.List;

public class MacroCommand implements Command {
    private List<Command> commands;

    public MacroCommand(List<Command> commands) {
        this.commands = commands;
    }

    @Override
    public void execute() {
        for (Command command : commands) {
            command.execute();
        }
    }

    @Override
    public void undo() {
        for (int i = commands.size() - 1; i >= 0; i--) {
            commands.get(i).undo();
        }
    }
}

撤销时为什么要逆序？因为操作是有依赖的。比如宏命令先执行“复制”，再执行“粘贴”。撤销时必须先撤销“粘贴”，否则文本还停留在粘贴后的状态，撤销复制就会乱套。这就像你穿衣服要先穿袜子再穿鞋，脱掉时必须先脱鞋再脱袜子一样。

宏命令还有助于做事务性操作。假设一个业务操作包含三步：扣库存、创建订单、发送通知。如果中间某一步失败，可以调用已经执行过的子命令的 undo()，把前面的步骤回滚掉。这其实就是一个简化版的事务补偿机制，在很多分布式系统里都能看到类似思想。

4. 命令模式其实可以更轻：Lambda 与函数式接口的极限简化

4.1 偷懒版：只有 execute() 的命令

命令模式在 Java 中经典实现通常要写很多类。如果你只是临时需要把一个动作传给别人，不要求支持撤销，可以只定义一个只含 execute() 的接口：

java复制public interface Action {
    void execute();
}

这个接口和 Java 自带的 Runnable 几乎没有区别。实际上，Runnable 就是一个“没有参数、没有返回值”的命令接口。很多框架里提交任务时传一个 Runnable，就是在用命令模式。

如果方法需要参数，可以把参数封装进闭包，或者使用现成的函数式接口。Java 8 之后，函数式接口让命令模式的实现轻便了很多。但这里有一个关键点：函数式接口天然适合“一条命令一个方法”的场景，却不太适合“命令对象要保存状态、支持撤销、需要被序列化”的场景。

4.2 Java 8 Lambda 怎么压掉那些命令类

假设不需要撤销，只想给按钮设置一个动作，用传统命令类写会很啰嗦。你可以直接这样：

java复制public interface Command {
    void execute();
}

Command lightOn = () -> light.on();

这也是一种命令模式，只不过 ConcreteCommand 被 Lambda 表达式替代了。从行为封装的角度看，效果是一样的：你定义了一个命令对象，把它传给 Invoker，由 Invoker 决定什么时候执行。

但如果你需要 undo()，Lambda 就有点尴尬了。因为 undo() 需要知道刚才执行之前的状态。比如开灯命令的 undo() 要调用灯 off()，光靠一个无状态的 Runnable 做不到。你必须用一个对象保存“正着做什么、反着做什么”这两组信息。

这时候可以用一个稍微聪明一点的类：

java复制public class LambdaCommand implements Command {
    private final Runnable executeAction;
    private final Runnable undoAction;

    public LambdaCommand(Runnable executeAction, Runnable undoAction) {
        this.executeAction = executeAction;
        this.undoAction = undoAction;
    }

    @Override
    public void execute() {
        executeAction.run();
    }

    @Override
    public void undo() {
        undoAction.run();
    }
}

然后在客户端装配：

java复制Command lightOnCommand = new LambdaCommand(light::on, light::off);
Command lightOffCommand = new LambdaCommand(light::off, light::on);

这样既保留了撤销能力，又没写一堆 LightOnCommand、LightOffCommand 类。对于内部使用、不需要跨模块复用的命令，这种做法非常香。但对于需要独立测试、需要扩展属性和序列化的命令，还是老老实实写独立类，别为了省代码牺牲可读性。

4.3 什么场景适合精简，什么场景必须保留完整类

我自己的判断标准是：命令是否会被持久化、是否会被多个触发源复用、是否包含复杂状态。

如果命令只是在一个方法里被临时装配，用完就丢，Lambda 版本最合适。如果你的命令要写进操作日志、跨系统发送、放进消息队列，那一定要用完整的类，并且把命令内容做成可序列化的数据。

更极端的做法是：命令类只保存业务参数，不保存 Receiver 引用。例如一个“关灯”指令，命令对象中只有 deviceId 和 action: off，真正执行时从注册中心找到设备再调用方法。这种设计在物联网平台、运维自动化平台里很常见。命令对象变成了一个普通的数据对象，而执行器负责根据参数找到 Receiver。这样命令对象可以被扔进 MQ、被存储到数据库、被另一个服务执行，非常灵活。

5. 命令模式和策略模式的区别：表象相似，本质不同

5.1 两者都是封装变化，但封装的单位不同

有很多人学完命令模式和策略模式之后，发现两者的类图长得非常像，都是“一个接口，多个实现类，一个上下文持有接口引用”。面试时也经常被问“命令模式和策略模式有什么区别”。如果答不上来，说明你可能只是背了类图，没有理解意图。

我个人总结的一句话是：

策略模式回答的是“怎么做这件事”，它封装的是算法；命令模式回答的是“谁来做、什么时候做、做完怎么反悔”，它封装的是动作。

策略模式的典型场景是支付。一个订单可以选择支付宝、微信、银行卡，每种支付方式就是一个策略。上下文中持有支付策略的引用，调用 pay() 完成支付。用户关心的是“支付方式不同”，不关心“支付动作之后要支持撤销”。

命令模式的典型场景是遥控器。用户按下按钮，遥控器调用命令的 execute()，命令调用设备的业务方法。这里更关心的是“按钮和动作解耦”“操作可以被记录和撤销”。

5.2 一个容易混淆的例子

假设你要实现一个文件压缩功能，支持 ZIP 和 GZIP。两个压缩算法的类都实现 Compressor 接口，compress() 方法各有实现。这是一个策略模式，因为你是在多种“算法”之间切换。

假设你要实现一个文本编辑器，每次保存文件时都要记录日志、更新状态栏、把文件写入磁盘。你可以把“保存”这组操作封装成一个 SaveCommand，把“另存为”封装成另一个命令。按钮可以设置任意命令，操作历史也可以保存命令列表。这是命令模式。

如果非要强行区分，可以看一个点：策略模式通常没有“撤销”这一说。 你切换了支付方式，不能说“再撤销一次切换”。但命令模式天生就适合带撤销。如果一个对象的接口里必须存在 undo()、redo()、log() 之类的方法，那它基本就是命令而不是策略。

5.3 模式选择判断表

这个表不绝对，但能帮你快速判断。遇到一个设计问题时，先问自己：我是想让调用方“换一种做法”，还是想让调用方“提交一个可回滚的动作”？答对了，模式基本就选对了。

6. 命令模式落地中最容易踩的四个坑

6.1 撤销栈里的命令引用持有太久

命令对象一旦进入撤销栈，就会被一直引用着。如果命令对象里持有大对象，比如整个文档内容、数据库连接、GUI 控件，那么即使这些大对象已经不需要了，因为撤销栈还持有引用，垃圾回收也释放不掉。久而久之，内存就被吃光了。

解决办法有几种：

• 命令对象只保存必要参数，不保存大对象。比如剪切命令只需要保存剪切位置和切割出来的文本，不需要保存整个编辑器实例。
• 限制撤销栈的深度。比如最多只保留 50 步，超出部分直接丢弃。
• 为不支持撤销的敏感命令提供 dispose() 方法，当命令被移除时主动释放资源。

我在项目里见过一次线上事故，就是因为撤销历史无限增长，每一条命令都持有一个数据库查询结果集，最终导致老年代内存持续上涨。这个问题的教训是：命令模式不是光加一个类就完事了，你还要考虑命令的生命周期管理。

6.2 命令对象没有做序列化，跨线程传递就出问题

命令对象经常会被传递到不同的线程、进程或服务中执行。比如一个异步任务队列，接收端需要用命令对象。如果命令对象持有 Receiver 引用，而 Receiver 是内存中的对象，序列化过不去。

更合适的做法是让命令变成“可序列化的数据 + 可反序列化的执行逻辑”。有些框架会把命令拆成两部分：指令数据和处理器。指令数据包含操作类型、业务参数；处理器根据指令数据找到真正的 Receiver 并执行。这样命令对象可以安全地进入消息队列，可以被消费者恢复。

如果你只是想在同一个进程里传递命令，不需要这么麻烦。但如果你在做微服务或者物联网平台，一定要早一点考虑命令的跨端表达能力，否则后面会很痛苦。

6.3 用“类爆炸”换灵活性时，记得防呆

命令模式最常被诟病的问题是：每个操作都要写一个类，类会爆炸。比如一个系统有 100 个操作，就有 100 个命令类，光维护这些类就很累。

我的应对方法有两个：

• 优先使用 Lambda 或内部类，把只有几行逻辑的命令就地解决，不单独建类。
• 如果确实要建类，就把命令类的命名和包结构设计好。比如按业务域分组，一个包放同一类设备的命令，避免所有命令堆在一个目录里。

另外，命令类通常要写一个无参构造器或者一个普通构造器，方便框架实例化。如果命令类要交给 Spring 管理，记得把依赖通过构造器传入，配合 @Component 扫描。不要到处用 new 创建命令，否则你会在测试和替换时发现根本装不上。

6.4 不是所有操作都值得命令化

有些朋友学了命令模式后，热血沸腾，把所有方法调用都封装成命令对象。结果代码爆炸、可读性下降、执行链路模糊，最后反而被同事嫌弃。

我的建议是：命令模式最适合的场景有三个特征。

• 操作需要被延迟执行。比如用户点击一个按钮，但真正执行要等到事务提交后。
• 操作需要支持撤销。没有撤销需求时，命令模式的很多优势体现不出来。
• 操作需要被组合成宏或队列。比如批量任务、自动化流程。

如果一个操作只是简单的同步调用，没有任何补偿、记录、排队的需求，那就不要为了设计模式而设计模式。好的设计模式，不是在代码里到处撒花，而是在合适的位置加入一层恰到好处的抽象。

我在实际项目中验证过一句话：命令模式最舒服的落地方式，不是在所有按钮上强制执行，而是先找到一个“必须支持撤销/记录/队列”的痛点，再用这个模式去重构那一处。 一旦同事看到重构后的代码比原来清爽，他们自然会慢慢接受这个模式。如果一开始就铺得太大，很容易因为阻力太大而中途放弃，最后变成一堆半吊子的命令类。

把这些经验沉淀下来之后，我后来再做工具栏、消息队列、事务补偿这类模块，都会先画一下命令的边界，再动手写代码。设计模式的书可以丢在一边，但这种“先想清楚动作的生命周期”的习惯，才是真正让代码不烂掉的关键。