设计模式这东西，放在C++里总是会多出几分味道来。你翻GoF那本经典书，命令模式（Command Pattern）的示例代码通常是用Java写的，类与方法规规矩矩，看起来人畜无害。但一到C++的工程现场，事情就变得有意思了：接口怎么写、生命周期谁管、撤销栈里放的是快照还是逆操作、要不要支持宏命令、队列里塞的是裸指针还是std::function……每一种选择都会把“命令模式”推向一个不同的变体。这篇文章我想认真聊的，不是把教科书里的类图再抄一遍，而是我在实际项目里见过的、用过的、踩过坑的那些C++命令模式变体——它们才是这个模式在真实世界里的样子。
读者里如果有正在做编辑器、游戏客户端、GUI框架或者任何“操作-撤销”系统的人，这篇文章能帮你理清思路；如果你只是刚开始接触设计模式，我也尽量用说人话的方式讲清楚每一处取舍。所有代码我都尽量给出可编译的片段，关键处会标注为什么这么写。
1. 先把“经典命令模式”讲透：为什么需要它
1.1 命令模式解决的核心问题
命令模式的核心思想，是把“请求”本身封装成一个对象。这样发起请求的人（调用者）不需要知道请求被谁处理、怎么处理，只需要把命令对象交出去，由接收者去执行。最常见的类比是餐厅点餐：你（客户）把订单（命令）交给服务员（调用者），服务员把订单递给后厨（接收者），后厨照着做菜。你不需要认识厨师，也不需要钻进厨房。
这个抽象带来的价值有三个。第一是解耦：业务操作和触发入口彻底分离，按钮、快捷键、脚本、网络消息都能用同一套命令对象去触发同一段逻辑。第二是可组合：命令对象可以排队、延迟、批量执行，甚至可以组合成宏命令。第三是可回溯：既然每个操作都被封装成了对象，我们自然可以在命令对象里实现undo/redo逻辑，让系统具备“时光倒流”的能力。
在C++里，命令模式还有一层特殊的意义：它能把“函数调用”这种静态绑定关系，转化为一种可以在运行时动态配置的“数据流”。这意味着你的核心逻辑可以被打包成对象，存放、传递、序列化，甚至在运行时从配置文件中创建出来。这是C++这类系统级语言特别看重的灵活性。
1.2 一个最朴素的C++实现
先看一个最标准的实现，几乎你翻开任何一本设计模式的书都能看到这样的结构。我们有抽象基类Command，有实现具体操作的ConcreteCommand，有一个持命令的调用者Invoker，以及真正干事儿的接收者Receiver。
#include <iostream> #include <memory> class Command { public: virtual ~Command() = default; virtual void execute() = 0; virtual void undo() = 0; }; class Receiver { public: void action(const std::string& msg) { std::cout << "Receiver: " << msg << std::endl; } }; class ConcreteCommand : public Command { public: ConcreteCommand(std::shared_ptr<Receiver> receiver, std::string msg) : receiver_(std::move(receiver)), msg_(std::move(msg)) {} void execute() override { receiver_->action(msg_); } void undo() override { // 逆操作逻辑，比如记录之前的状态并恢复 std::cout << "Undo: rollback " << msg_ << std::endl; } private: std::shared_ptr<Receiver> receiver_; std::string msg_; }; class Invoker { public: void setCommand(std::shared_ptr<Command> cmd) { command_ = std::move(cmd); } void run() { if (command_) { command_->execute(); } } private: std::shared_ptr<Command> command_; }; int main() { auto receiver = std::make_shared<Receiver>(); auto cmd = std::make_shared<ConcreteCommand>(receiver, "hello command"); Invoker invoker; invoker.setCommand(cmd); invoker.run(); // 输出: Receiver: hello command return 0; }这段代码本身没有问题，但你很快会察觉到几个痛点。第一，类爆炸。每来一个新的操作，你就要新增一个ConcreteCommand的子类，哪怕它的逻辑只有一行调用，也得单独定义类、写构造函数、实现execute和undo。业务一旦多起来，项目里全是这种只有几行逻辑却独占一个文件的小类。第二，基础设施代码重复。接收者指针、参数存储、构造函数的写法几乎没有差别，全是样板代码。第三，undo的实现往往不是简单的“再调一个函数”，它往往依赖命令执行前的状态快照，这就暴露出经典设计里没有细说的复杂度。
所以，在真实的C++工程里，几乎很少有人按照这种最原始的方式去组织大量命令。大家更愿意用语言特性去“变体化”这个模式，让它更贴合业务。
2. C++里的头号变体：用std::function“消灭”命令类
2.1 从命令类到可调用对象
C++11之后，std::function的出现让“命令模式”的形态发生了一个很有意思的变化。你不再需要为每一个操作定义类，因为std::function<void()>本质上就是一个“命令对象”——它封装了一段可执行逻辑，可以被存储、复制、转移和调用。配合lambda表达式，我们可以把一个具体操作按需打包成命令，直接用，不需要造类。
这就是我所说的头号变体：命令模式从“类多态”走向“函数式封装”。这种变体在实现上极其轻量，也是我在日常工作里最常用的一种写法。看下面的代码：
#include <functional> #include <iostream> #include <vector> class Editor { public: void insertText(const std::string& text) { std::cout << "Insert: " << text << std::endl; } void deleteText(int len) { std::cout << "Delete: " << len << " chars" << std::endl; } }; class CommandStack { public: using Command = std::function<void()>; void execute(Command cmd) { if (cmd) { cmd(); } } void addUndo(Command cmd) { undoStack_.push_back(std::move(cmd)); } void undo() { if (undoStack_.empty()) return; auto cmd = std::move(undoStack_.back()); undoStack_.pop_back(); if (cmd) cmd(); } private: std::vector<Command> undoStack_; }; int main() { Editor editor; CommandStack stack; // 方法一：直接用lambda包装 auto insertHello = [&editor]() { editor.insertText("hello"); }; stack.execute(insertHello); // 模拟一条带撤销的命令 auto insertWorld = [&editor]() { editor.insertText("world"); }; auto undoInsertWorld = [&editor]() { editor.deleteText(5); }; stack.execute(insertWorld); stack.addUndo(undoInsertWorld); stack.undo(); // 输出: Delete: 5 chars return 0; }你看，我们没有写任何Command子类，也没有接收者接口，只是用了两个lambda和一个std::function容器，就把命令模式的骨架搭起来了。这种变体的好处是极其明显的：对于一次性或者低频的操作，你根本不需要去设计类层次，直接在调用点写lambda就完事了。业务代码的密度明显提升，工程结构也变得更扁平。
2.2 撤销操作怎么在函数式变体里实现
有人可能会问：lambda都捕获了外部变量，撤销怎么实现？其实思路不变：你在提交命令时，同时把一个“反向操作”的lambda保存到undo栈里。上面代码里undoInsertWorld就是一个逆操作，它知道自己做了插入，撤销时就删除同样长度的文本。
更进一步，如果一条命令既有正向执行、又有逆向撤销，我们也可以组织成一个pair，把它当成一个完整的“命令对象”来用：
struct CommandPair { std::function<void()> doIt; std::function<void()> undoIt; };CommandPair的使用方式，比传统的Command基类更加灵活。你可以把它放在std::vector里，可以按条件构造，甚至可以从配置文件里动态决定do和undo的lambda赋值。这种结构在编写编辑器工具时非常常见，我见过不少轻量级工具，整个撤销系统就是围绕一个std::vector<CommandPair>来构建的。
但要注意一点，“函数式命令”并不是万能的。lambda最大的问题是它“太灵活”了——它把命令的类型信息抹掉了。当你需要区分命令种类、需要把命令序列化持久化、需要支持脚本录制回放时，std::function这种形态就会变得很难处理。因为这些场景里，你不仅需要“调用逻辑”，还需要“描述命令的元数据”，而lambda里没有这个信息。所以，重型系统里仍然需要回到带有标识的类对象，或者组合使用两者。
3. 可撤销与重做：状态型变体的设计与陷阱
3.1 快照式撤销：什么时候该用
在文档编辑器、画图工具、关卡编辑器这类场景里，“撤销”不是简单执行一个逆操作就可以了。比如你在图像编辑器里给图层加了一个滤镜，逆操作是什么？你怎么“减去一个滤镜”？最稳妥的办法，是在执行命令之前先保存整个对象的状态快照，撤销时直接恢复快照。这就是快照式撤销。
这种方案的优点是简单、无脑、可靠，不会出现逆操作算错的情况。缺点是内存占用大、执行速度慢。对于小的文档这无所谓，但对大型场景来说，每次操作都存一份全量快照会迅速吃光内存。
写个基本的样子：
#include <memory> #include <vector> #include <iostream> // 简化：场景对象，包含一些可序列化的数据 struct SceneState { std::string serializedData; }; class Scene { public: SceneState snapshot() const { SceneState state; state.serializedData = data_; return state; } void restore(const SceneState& state) { data_ = state.serializedData; std::cout << "Scene restored. data = " << data_ << std::endl; } void setData(const std::string& d) { data_ = d; } private: std::string data_; }; class UndoManager { public: void pushSnapshot(const SceneState& before, const SceneState& after) { states_.push_back({before, after}); } void undo(Scene* scene) { if (states_.empty()) return; auto& [before, after] = states_.back(); scene->restore(before); states_.pop_back(); } private: std::vector<std::pair<SceneState, SceneState>> states_; };现实工程里，快照一般都是把场景对象序列化成字节流或JSON来存，内存里同时保留前后两份状态。实操心得是：压缩可以，但不要直接把原始数据存成字符串，尤其是大场景，每次操作都产生几十MB字符串的撤销栈会让人崩溃。我见过一个开源编辑器项目，最初用std::string存全场景JSON，结果连续操作几十步后内存占用飙到几个GB，后来改成二进制快照加压缩，同样功能内存占用降到原来的十分之一。这个优化值得做。
3.2 逆操作式撤销：什么时候该用
与快照相对的，是逆操作式撤销。你记录的不是状态，而是“怎么倒回去”的操作本身。比如插入文字，撤销就是删除同样位置同样长度的文字；移动图元，撤销就是把它再移回去。这种方式的优点是速度快、内存小，但缺点是需要你保证逆操作是正确且完备的。一旦某个操作不满足可逆性（比如删除文件），你就必须退回到快照或者干脆禁止撤销。
做逆操作式撤销有一个非常容易踩坑的点：逆操作必须精确记录上下文。举个例子，你在文字编辑器里把光标后面的第3个字符删掉了。你的undo如果只是“恢复删除”，但当时光标位置、被删字符的具体内容、删除后是否有字符移动……全都要记录。如果漏掉一个信息，撤销结果就会错乱。所以写逆操作式撤销时，我的习惯是：先把“正向动作需要用到哪些上下文”的清单列出来，再对称地列“逆向动作需要哪些上下文”，两边对齐了才动手写代码。
3.3 命令栈管理的细节
无论是快照式还是逆操作式，命令栈本身的管理都有一些通用细节需要考虑。第一个问题是栈需要设置上限。编辑器不可能无限撤销，通常几百步封顶，超出的步骤要从栈底丢弃。实现上用std::deque比std::vector更合适，因为头部弹出不需要搬移元素。
第二个问题是redo栈的清理时机。标准的做法是：任何新命令执行后，清空整个redo栈。逻辑很简单，因为你已经走出了一条新分支，原来那些“重做”记录就无效了。这个判断要放在execute动作的入口处，统一处理。
第三个问题是分组记录。很多编辑器把连续的几十次输入合成一组，用户按一次Ctrl+Z回退整个词或整个操作序列。实现时可以在栈上打标记，分组之间插入特殊的分隔记录。注意区分“命令分组”和“事务”，概念虽像，实现位置不同。
// 用deque管理undo栈 + 分组标记 struct CommandEntry { bool isGroupBoundary; std::function<void()> undoFn; }; class UndoManagerImpl { public: void beginGroup() { undoStack_.push_back({true, nullptr}); } void push(std::function<void()> undoFn) { undoStack_.push_back({false, std::move(undoFn)}); redoStack_.clear(); } void undo() { if (undoStack_.empty()) return; // 至少回退到一个分组边界 do { auto entry = std::move(undoStack_.back()); undoStack_.pop_back(); if (entry.undoFn) { entry.undoFn(); redoStack_.push_back(std::move(entry)); // 简化重做 } if (entry.isGroupBoundary) break; } while (!undoStack_.empty()); } private: std::deque<CommandEntry> undoStack_; std::deque<CommandEntry> redoStack_; };上面的代码是一种常见的分组简化实现，真实产品里会有更多状态管理，但核心思想就是这样：用边界标记控制undo的回退粒度。
4. 宏命令与命令队列：把命令组合起来的变体
4.1 组合命令与“宏录制”
命令模式的另一个经典变体是宏命令：把多个命令打包成一个命令，一起执行、一起撤销。这在脚本录制、自动化操作、批量处理里特别常见。比如用户在界面上做了一系列操作，系统把这些操作录制成一个Composite命令，回放时一次性执行。
GoF里的实现是让MacroCommand也实现Command接口，内部持有一个命令列表。但C++里我们同样可以用std::function简化它。更实用的一种宏命令设计，是让宏命令在执行时动态地重新执行列表里的命令，同时把撤销命令也收集起来。
#include <vector> #include <functional> #include <iostream> class MacroCommand { public: using Command = std::function<void()>; void add(Command cmd) { commands_.push_back(std::move(cmd)); } void execute() { for (auto& cmd : commands_) { if (cmd) cmd(); } } void undo() { // 逆序执行所有逆操作 for (auto it = reverseCommands_.rbegin(); it != reverseCommands_.rend(); ++it) { if (*it) (*it)(); } reverseCommands_.clear(); } void pushReverse(Command rev) { reverseCommands_.push_back(std::move(rev)); } private: std::vector<Command> commands_; std::vector<Command> reverseCommands_; };宏命令的要点在于录制与回放的对称性。录制时不仅要知道“正着做什么”，还要能收集“反着怎么做”。我见过很多团队一开始只实现了宏执行，没实现宏撤销，做到一半发现撤销已经无法接回去了。这里还是要复用第3节的核心思路：要么每个子命令都提供逆操作，要么整个宏命令在开始时对全局状态做一次快照。两者至少要占一个，否则宏命令的撤销就是空的。
4.2 线程安全的命令队列
命令模式还有一个很常见的应用场景，是把命令放进一个队列，由后台线程依次消费。这在图形系统、网络消息处理、音频引擎里都能看到。比如主线程产生UI命令，工作线程执行耗时操作；或者网络线程收到指令，推入队列，主线程在下一帧取出执行。
C++里做一个线程安全的命令队列，要比Java容易踩坑。核心要保护两个东西：队列本身的push/pop，以及条件变量唤醒的使用。
#include <queue> #include <mutex> #include <condition_variable> #include <functional> #include <thread> #include <iostream> class CommandQueue { public: using Command = std::function<void()>; void push(Command cmd) { { std::lock_guard<std::mutex> lock(mutex_); queue_.push(std::move(cmd)); } cv_.notify_one(); } Command pop() { std::unique_lock<std::mutex> lock(mutex_); cv_.wait(lock, [this] { return !queue_.empty() || stop_; }); if (stop_ && queue_.empty()) { return nullptr; } auto cmd = std::move(queue_.front()); queue_.pop(); return cmd; } void stop() { { std::lock_guard<std::mutex> lock(mutex_); stop_ = true; } cv_.notify_all(); } private: std::queue<Command> queue_; std::mutex mutex_; std::condition_variable cv_; bool stop_ = false; }; void worker(CommandQueue* queue) { while (true) { auto cmd = queue->pop(); if (!cmd) break; cmd(); } } int main() { CommandQueue queue; std::thread t(worker, &queue); for (int i = 0; i < 5; ++i) { queue.push([i] { std::cout << "Run command " << i << std::endl; }); } std::this_thread::sleep_for(std::chrono::milliseconds(100)); queue.stop(); t.join(); return 0; }这里的几个细节值得反复强调。第一，pop里用条件变量时必须传入一个lambda作为谓词，避免伪唤醒。第二，stop_标志要在锁内更新，同时在锁内判断队列是否为空再返回nullptr，不然你可能会在stop后还从队列里捞到一条命令，然后又错过它。第三，push里要先释放锁再notify，还是先notify再释放锁？严格按上面代码的写法，先释放锁再notify_one是可以接受的做法，避免通知时新线程立刻尝试抢锁而再次阻塞，能轻微减少无谓的上下文切换。
还有一点，命令对象里的捕获生命周期。如果命令捕获了裸指针，你得保证在命令执行之前指针指向的对象始终存活。线程队列场景里这是最隐蔽的内存问题，简单说：让业务对象使用std::shared_ptr，命令捕获它的拷贝。这条经验值一条严重的线上崩溃事故。
5. 与其它模式联动：命令工厂、命令原型和GUI中的应用
5.1 命令+工厂：让命令对象可以按配置生成
当命令的种类足够多，且创建逻辑需要根据配置动态变化时，把命令模式和工厂模式结合起来会很顺手。比如一个可扩展的插件系统，插件寄存器负责按字符串ID创建命令对象。这种“命令工厂”变体的价值在于，你可以把用户输入、脚本字符串、网络消息映射到对应的命令对象，不需要在业务层堆一大堆if-else。
典型的抽象设计如下：
#include <unordered_map> #include <memory> #include <string> class CommandBase { public: virtual ~CommandBase() = default; virtual void execute() = 0; virtual std::string name() const = 0; }; using CommandPtr = std::shared_ptr<CommandBase>; using CommandCreator = std::function<CommandPtr()>; class CommandFactory { public: void registerCommand(const std::string& id, CommandCreator creator) { creators_[id] = std::move(creator); } CommandPtr create(const std::string& id) const { auto it = creators_.find(id); if (it == creators_.end()) { throw std::runtime_error("command not found: " + id); } return (it->second)(); } private: std::unordered_map<std::string, CommandCreator> creators_; };实际项目中，工厂创建的命令还需要搭配参数。一个更通用的做法是给create传入一个KV参数包，命令对象在构造时按需读取。这样外部只需要传一个ID和配置表，就能生成完整的命令对象。
5.2 命令+原型：克隆命令的技巧
命令对象有时也需要被复制，尤其是当你需要把命令持久化到文件、网络传输或者创建多个相似命令时。这就是命令+原型模式的变体。用C++实现时，可以给命令基类增加一个纯虚clone()方法，返回一份深拷贝。
class CloneableCommand : public CommandBase { public: std::unique_ptr<CloneableCommand> clone() const { return std::unique_ptr<CloneableCommand>(cloneImpl()); } private: virtual CloneableCommand* cloneImpl() const = 0; }; class AddItemCommand : public CloneableCommand { public: explicit AddItemCommand(std::string item) : item_(std::move(item)) {} void execute() override { /* ... */ } std::string name() const override { return "AddItem"; } private: AddItemCommand* cloneImpl() const override { return new AddItemCommand(*this); } std::string item_; };这里clone返回的是unique_ptr，避免裸指针到处飞。注意，如果你的命令对象内部有接收者指针，克隆时要决定是“共享同一个接收者”还是“复制一个新的接收者”。大多数编辑器场景里，接收者是全局唯一的，所以共享指针。但如果命令管理着独立的参数副本，那参数部分要深拷贝。这个区分一定要想清楚，否则会出现改了一个命令副本的参数，原本命令也跟着变的问题。
5.3 在GUI和游戏输入中的应用
聊了这么多变体，落到实际场景里最好理解的还是GUI和游戏输入。
在GUI框架中，按钮点击、菜单项选中、快捷键触发，本质上都只是“用户的某种意图”。把这些意图统一封装成命令后，按钮只负责持有命令并在点击时调用execute，菜单项也是一样，快捷键也一样。这样要改一个功能的位置，只需要换绑命令，完全不用动界面代码。这也是Qt里QAction、著名底层GUI框架里Command之间关系的基础。
在游戏输入系统里，命令模式更是标配。玩家按“跳跃”键，按键映射表把物理键映射到一个逻辑动作ID，再由一个命令工厂创建对应的命令对象交给玩家角色执行。这样做的好处是显而易见的：支持键位自定义、支持手柄/键盘切换、支持Ai也产生同样的逻辑命令。我参与过的某跨平台系统，输入层统一产出命令对象，模拟器测试也走同一套命令通道，排查问题非常方便。
这条经验我想再强调一遍：把输入和逻辑完全解耦，用命令对象作为唯一绑定点，无论是做UI还是做游戏输入，这都是命令模式给你带来的最大功效。
6. 命令模式的常见坑与排查建议
6.1 内存生命周期问题
C++里命令模式最大的坑，就是生命周期管理。命令对象可能被存到栈里、队列里，还可能被复制多份。如果你用的是裸指针，接收者先于命令被销毁，那执行命令就是一记“悬空指针调用”，直接崩溃。
最佳实践是用std::shared_ptr管理接收者和命令对象，除非你能证明std::unique_ptr足够且安全。注意，撤销栈里保存的命令副本和正在执行的命令副本，本质上应该共享底层资源，不要为每份命令副本都复制一遍接收者。用shared_ptr结构，浅拷贝正好能符合这种共享语义，而参数数据如果可变，再按需深拷贝。
6.2 重入与递归问题
命令模式执行时，一个不慎就会出现递归调用。比如在命令的execute里又触发了一个事件，事件又创建并执行了另一个命令，导致命令栈无限增长。调试时你会看到调用栈深不见底，但查代码哪里都对，这种问题最烦人。
我的排查经验是：在execute入口处加一个简易的“执行中”标志或深度计数。超过阈值就抛出异常或直接拒绝。另外，在UI事件驱动代码里，命令执行期间尽量屏蔽同类型事件的重入。有时一个命令内部调用了另一个命令，这是合法嵌套，所以阈值比bool标志更好用。
6.3 性能考量
命令模式虽然优雅，但也不能滥用。每次execute都是一次虚函数调用或std::function调用，相比直接调用函数有额外的开销，虽然在绝大多数业务逻辑里可以忽略，但在每帧几千次执行的引擎热路径上，这个开销会被放大。
另外，快照式撤销如果频繁把大对象拷贝到内存，CPU和内存都会报警。我常用的优化手段依次是：只记录增量变化而不是全量快照；快照使用写时复制（copy-on-write）的共享数据结构；压缩存储;批量合并高频小操作。这四招从粗到细，能覆盖绝大多数性能问题。
排查性能问题时，不要凭感觉，用性能分析工具看一眼命令栈里的耗时分布。你会发现很多时候瓶颈不在命令模式本身，而在命令内部执行了重操作。但如果你发现单纯是命令调度开销占了1%以上的CPU，那就要考虑合并命令或者优化调用路径了。
最后再分享一个小技巧。如果你在维护一套复杂到已经有一堆命令类的系统，试着每周抽出点时间给命令类写“冒烟测试”：为每个命令构造一个小输入，跑一遍execute，跑一遍undo，再确认结果回到初始状态。这个简单的回归测试，能帮你挡住至少一半跟状态管理有关的借位bug。我自己的经验是，命令模式一旦普及，撤销栈相关的bug几乎都是状态没保存好或逆操作没写对，提前有测试基线，后面排查问题会省非常多的力气。
