写代码这么多年，几乎每个项目都会碰到“撤销/重做、操作队列、批量指令”这类需求。一开始我也爱直接写if-else，把操作类型当作枚举值，switch里塞逻辑，前几版确实爽，等需求一变就知道疼了：新加一个操作要改三四个地方，测试用例写得想吐，调用方和实现方根本解耦不了。后来认认真真把命令模式（Command Pattern）用进C++项目里，才算是把这一类问题彻底理顺。
这篇东西不打算写成设计模式教科书，而是从我实际踩坑的角度，讲清楚命令模式在C++里到底怎么落地：为什么值得用、接口该怎么设计、现代C++有哪些更好的写法、撤销和重做这类经典场景怎么搭、以及我吃过亏的几个细节。适合正在写C++业务代码、想优化架构的同学，也适合准备C++面试时把设计模式讲出点实在东西的人。
1. 命令模式到底是什么——先搞清楚它解决了什么问题
1.1 一个看似简单却越改越烂的需求
先看一个特别典型的场景。假设你正在做一个文本编辑器，界面上有一排按钮：新建、插入文字、删除、加粗、查找替换。最简单的实现方式就是每个按钮的点击事件里直接调用对应函数：
Button button; button.onClick = [&]() { editor.insert("hello"); editor.bold(2, 5); };这段代码本身没问题，问题出现在“需求演进”的时候。产品经理第二天过来说：加个撤销功能。你打开源码一看傻眼了，因为编辑器对象已经被写了好几个地方，所有点击逻辑都直接操作editor，没有任何“操作记录”。你想把每一步操作封装成可撤销的单元，就只能改所有调用点，加一个操作历史栈，然后为每一种操作写对应的恢复逻辑。
这时候命令模式的思路就能帮上忙：把“操作”本身提升为一个对象，而不是方法调用。每个操作对象知道自己怎么执行、怎么撤销，调用方只需要把操作对象扔给一个统一的管理器，剩下的由管理器自己完成。
1.2 命令模式的四个经典角色
理论上，命令模式由四个角色组成：
- Command（抽象命令）：定义统一接口，通常包含execute和undo。
- ConcreteCommand（具体命令）：实现具体操作，持有接收者的引用。
- Receiver（接收者）：真正干活的业务对象，比如编辑器、文档、数据库。
- Invoker（调用者/请求发起者）：持有命令对象，在合适的时机触发execute。
翻译成大白话：Receiver是厨房里的大厨，ConcreteCommand是一张写着“宫保鸡丁做法”的订单，Invoker是前台服务员，并不关心菜怎么做，只负责把订单递给后厨。客人不会直接跑进厨房说“放点醋”，而是跟前台说“我要一份宫保鸡丁”，这就是请求的封装和发送分离。
这个模式真正厉害的地方在于：调用方不依赖具体的操作实现。前端按钮只需要知道“我手里有一个可以execute的东西”，至于执行后是对数据库做了更新、对文件做了写入还是弹了个窗口，它一概不知。这个解耦粒度在维护期会产生巨大的价值——你完全不用改调用方代码就能扩展新功能。
2. 设计一个能用的接口——从我在C++里的真实项目讲起
2.1 命令接口要不要支持撤销
很多设计模式文章都会把命令模式定义为“执行请求的对象化”，然后把撤销当成一个可选议题。但在C++桌面应用、编辑器的实战场景里，我强烈建议从第一天就设计undo接口。原因很简单：后期加undo的成本远高于前期预留。
撤销接口的本质是“反向操作”的抽象。你要么在每个命令里保存操作前后的快照，要么让Receiver支持反向操作。接口上一旦定义了undo，所有命令类都必须实现它，这就形成了一种强制约束，逼着设计者考虑状态恢复的问题。
一个比较完整的接口大致长这样：
class Command { public: virtual ~Command() = default; virtual void execute() = 0; virtual void undo() = 0; // 有些命令不支持撤销，默认置空 virtual bool canUndo() const { return true; } };注意，我把canUndo也放进了接口。理由是有些命令执行完就不可逆，比如“从内存缓存中释放数据”这种操作，你把数据删了，反向操作根本无从谈起。在Invoker里判断canUndo再决定是否入栈，比让命令抛异常优雅得多。
2.2 谁应该成为Receiver
我见过不少初学者写命令模式，把所有业务逻辑一股脑塞进ConcreteCommand。比如做一个“保存文件”的命令，他直接在execute里写fopen、fwrite、fclose，搞得命令类变成一个巨型类，这其实就跑偏了。
命令模式的核心分工是：命令类只负责“参数绑定”和“流程编排”，真正的数据操作必须下沉到Receiver。
我给你打个比方。命令对象是一张支票，Receiver是银行。支票上写金额和收款人，但它本身不是钱。你拿着支票去柜台，柜台验证后让银行系统转账。如果支票自己就把钱转了，那还要系统干嘛？合理拆分之后，多个命令可以共享同一个Receiver的底层能力，比如insert和delete都调用EditorDocument的insertText和deleteRange，而不是各自实现一遍文本编辑逻辑。
C++项目里Receiver往往就是业务聚合根，比如文档、图片缓冲区、网络会话。设计时尽量让Receiver提供的是“原子操作”，这样命令类组合起来才灵活。
2.3 接口版的标准实现架构
直接上一个可运行的最小骨架，把类之间的关系展清楚：
// Receiver：实际干活的业务对象 class Editor { public: void insertText(size_t pos, const std::string& text) { m_text.insert(pos, text); } void eraseText(size_t pos, size_t len) { m_text.erase(pos, len); } const std::string& text() const { return m_text; } private: std::string m_text; }; // 命令接口 class Command { public: virtual ~Command() = default; virtual void execute() = 0; virtual void undo() = 0; }; // 具体命令：插入文字 class InsertCommand : public Command { public: InsertCommand(Editor& editor, size_t pos, std::string text) : m_editor(editor), m_pos(pos), m_text(std::move(text)) {} void execute() override { m_editor.insertText(m_pos, m_text); } void undo() override { m_editor.eraseText(m_pos, m_text.size()); } private: Editor& m_editor; size_t m_pos; std::string m_text; }; // 具体命令：删除文字 class DeleteCommand : public Command { public: DeleteCommand(Editor& editor, size_t pos, size_t len) : m_editor(editor), m_pos(pos), m_len(len), m_savedText("") {} void execute() override { m_savedText = m_editor.text().substr(m_pos, m_len); m_editor.eraseText(m_pos, m_len); } void undo() override { m_editor.insertText(m_pos, m_savedText); } private: Editor& m_editor; size_t m_pos; size_t m_len; std::string m_savedText; // 执行时保存被删内容 };这段代码里有一个关键设计：DeleteCommand在执行时才把被删文本存下来。这意味着刻录到命令里的不是执行时的空指针或悬空引用，而是实际数据。这个习惯很重要，尤其是遇到需要撤销的命令，尽量通过保存数据来实现，而不是依赖外部快照，因为外部快照很容易因为时序问题覆盖掉其他命令的结果。
3. Invoker和撤销栈——把命令串起来执行
3.1 Invoker的核心职责
Invoker是整个模式里最容易被低估的角色。很多人觉得它不就是调用一下execute嘛，有什么好设计的？实际开发里，Invoker还需要负责命令生命周期管理、撤销栈维护、以及复合操作的原子性。
一个带撤销功能的编辑器Invoker大概长这样：
class CommandHistory { public: void push(std::unique_ptr<Command> cmd) { cmd->execute(); m_undoStack.push(std::move(cmd)); // 新命令执行后，重做栈应该清空 std::stack<std::unique_ptr<Command>> empty; std::swap(m_redoStack, empty); } void undo() { if (m_undoStack.empty()) return; auto cmd = std::move(m_undoStack.top()); m_undoStack.pop(); cmd->undo(); m_redoStack.push(std::move(cmd)); } void redo() { if (m_redoStack.empty()) return; auto cmd = std::move(m_redoStack.top()); m_redoStack.pop(); cmd->execute(); m_undoStack.push(std::move(cmd)); } bool canUndo() const { return !m_undoStack.empty(); } bool canRedo() const { return !m_redoStack.empty(); } private: std::stack<std::unique_ptr<Command>> m_undoStack; std::stack<std::unique_ptr<Command>> m_redoStack; };这段代码有一个特别重要的点：必须使用std::unique_ptr来管理命令对象，而不是裸指针。
道理很简单，命令对象生命周期横跨多个执行点，如果使用裸指针，Invoker和调用方就要商量“谁delete、什么时候delete”，这种约定只要一个人忘了，就是内存泄漏或者更可怕的悬空指针。unique_ptr把所有权明确交给Invoker，到栈销毁时自动释放，符合C++的RAII惯例，整个模式一下子变得非常安全。
还有个细节是redo栈的清理：当用户按了新命令后，旧的redo历史应该全部清空，这是所有编辑器软件的标准行为。如果你不清空，第一次undo后再次执行新操作，原来的redo路径就会和现在的操作混淆，行为变得不可预测。
3.2 复合命令：让撤销具备“原子性”
实战里经常遇到这种情况：用户一键拖拽了三个控件，而这三个控件的移动是三条独立命令。如果让三条命令分别入栈，用户撤销时就得按三次Ctrl+Z，然后发现撤销到一半界面错乱了——因为控件A恢复了位置，控件B、C还在新的位置，整个布局跟用户记忆对不上。
所以要引入CompositeCommand，也称“宏命令”，它把多条子命令打包成一条命令，统一执行、统一撤销：
class CompoundCommand : public Command { public: void add(std::unique_ptr<Command> cmd) { m_commands.push_back(std::move(cmd)); } void execute() override { for (auto& cmd : m_commands) { cmd->execute(); } } void undo() override { // 注意：撤销必须逆序 for (auto it = m_commands.rbegin(); it != m_commands.rend(); ++it) { (*it)->undo(); } } private: std::vector<std::unique_ptr<Command>> m_commands; };那个反序撤销的细节绝对属于经验之谈。想象一下命令队列是“先移动A，再移动B”，撤销时如果正序恢复就会出现先B回原位、后A回原位，中间瞬间的状态跟执行顺序相悖。虽然最终结果一致，但如果有实时渲染，用户能看到明显的跳变。逆序撤销保证每一步都严格回退执行顺序，视觉上和行为上都更自然。
4. 现代C++的轻盈写法——用std::function替代抽象基类
4.1 为什么基类版本不是唯一答案
前面那套标准接口版算是教科书方案，但你在项目里待久了就会发现，很多命令其实就一两行逻辑，非要去定义一个类，申明execute/undo，太过隆重。比如“把当前时间写入日志”这种操作，做成一个匿名lambda就完事，非要继承一个抽象类，反而降低可读性。
C++11之后，std::function + lambda给出了一条更轻的路线。命令不再是一个类，而是一组可调用的函数对象：
class Command { public: std::function<void()> execute; std::function<void()> undo; bool canUndo = true; };使用时直接通过lambda捕获：
std::string myText; auto insertCmd = std::make_shared<Command>(); insertCmd->execute = [&]() { myText.append("hello"); }; insertCmd->undo = [&]() { if (myText.size() >= 5) myText.resize(myText.size() - 5); };这种写法的好处是开发效率极高。你不必为临时操作创建专门类，直接在业务逻辑附近用lambda定义，可读性好得不是一点半点。代价是std::function本身有type erasure开销，每一次调用会多一层间接跳转，极端高频场景会有几纳秒级损耗。但大部分业务项目根本到不了那个量级，我更在意的是代码结构清爽。
4.2 泛型实现：让所有类自动支持命令化
C++14后还可以用泛型在编译期做一点黑魔法：不用改类定义，给类外层包一层通用命令适配器。比如我想让任意类的任意成员函数自动变成命令：
template <typename T> class MemberCommand : public Command { public: using MemberFunc = void(T::*)(); MemberCommand(T& obj, MemberFunc func) : m_obj(obj), m_func(func) {} void execute() override { (m_obj.*m_func)(); } private: T& m_obj; MemberFunc m_func; };这个写法更适合那种“很多类都有相似操作”的场景。比如游戏里每个单位都有move动作，用MemberCommand来统一封装，比每个单位各自写一套命令类要省事得多。不过要注意，它牺牲的是灵活性和可读性，后续维护时定位具体逻辑会多一层间接，所以用不用得权衡。
4.3 现代C++建议的组合方案
我个人在C++17项目里推荐的姿势是组合拳——核心框架用抽象接口保证扩展性，简单命令用std::function快速定义，复合命令用CompoundCommand拼装。三种方式不冲突，核心接口稳定，业务层灵活。下面这个类同时提供函数式接口和类式接口：
class Command { public: // 类实现者重写 virtual void execute() {} virtual void undo() {} // 静态工厂：函数式定义命令 static std::shared_ptr<Command> fromFunc( std::function<void()> exec, std::function<void()> unexec = nullptr) { class FuncCommand : public Command { public: FuncCommand(std::function<void()> e, std::function<void()> u) : m_exec(std::move(e)), m_unexec(std::move(u)) {} void execute() override { m_exec(); } void undo() override { if (m_unexec) m_unexec(); } private: std::function<void()> m_exec; std::function<void()> m_unexec; }; return std::make_shared<FuncCommand>(std::move(exec), std::move(unexec)); } };这样界面上既有“传统继承式”的扩展空间，又有“lambda即用即走”的便利。实际项目里我会在代码注释里约定：超过50行的逻辑走继承类，简单的一次性操作走fromFunc，团队里用起来非常顺手。
5. C++实现中的细节陷阱——走过必踩，踩过必记
5.1 捕获方式的坑：lambda里的引用捕获
函数式命令极大提升了便利性，但很自然地引出一个大坑：lambda捕获的生命周期。
看这个例子：
CommandHistory history; { Editor tempEditor; auto cmd = Command::fromFunc( [&]() { tempEditor.insertText(0, "x"); }, [&]() { tempEditor.eraseText(0, 1); } ); history.push(std::move(cmd)); } // tempEditor在这里析构了 history.undo(); // 悬空引用！崩！代码看起来没毛病，实际上tempEditor出了作用域就被析构，undo时访问一块已释放的栈内存。这个问题非常隐蔽，因为它在编译期根本不会报错，甚至运行期也不一定立刻崩——只有堆内存被其他数据复用后，才会出现诡异的数据错乱。
我总结出来的规矩很简单：凡是进入命令历史栈的命令，捕获的对象生命周期必须大于历史栈本身。要保证这一点，最稳妥的做法是让Receiver拥有一个长生命周期（比如存在堆上）或者使用shared_ptr共享所有权，把对象存活期跟命令进行绑定。
5.2 不可复制对象与对象移动
C++的命令对象经常持有资源（文件句柄、网络连接、数据库会话），这类对象不可复制，只能移动。但很尴尬的是传统命令基类会定义虚函数，而虚函数的存在让移动操作的默认行为有风险——你用unique_ptr管理命令对象，就几乎没任何问题。
所以我的建议是：命令对象只允许用unique_ptr或shared_ptr传递，绝不裸拷贝、裸new、裸delete。这不是偏好，是C++资源所有权设计的基本盘。Invoker里顶多发生栈的pop/push和unique_ptr的移动，成本极低，安全性极高。
5.3 异常安全与执行中断
execute函数里如果抛出异常，Invoker的状态就乱了：命令栈没推进，但收到者可能执行了一半操作。这是C++特有的问题，因为C++允许你执行一句throw。
处理方式，经验是先约定：execute里不允许直接抛出业务异常，所有错误统一转为错误码或optional返回。如果要追求严格，Invoker可以这么兜底：
void safeExecute(Command* cmd) { try { cmd->execute(); } catch (...) { // 记录日志，但不往里压栈 // 必要时调用cmd->undo()做回滚 throw; // 或者吞掉 } }单靠try-catch本身并不能保证一致性。最严谨的实践是：在命令执行前先记录必要的状态，命令失败后立刻做rollback，保证业务状态不处于半更新状态。这个思路已经跳出命令模式本身，进入事务处理的范畴，但值得在大型项目里推广。
6. 实战场景复盘：我用命令模式重写的一个编辑器操作模块
6.1 需求与背景
前些时候我需要为一个富文本编辑器加上完整的操作历史。最初版本直接在Editor类内部实现了undo/redo函数，结果就是十几个互相纠缠的函数，没有任何统一抽象样式，新增一个“图片缩放”操作就得改Editor类本身，改完发现已有的undo逻辑错位，乱成一锅粥。
重构时我先把所有操作梳理成四类：插入、删除、格式调整、多媒体插入。然后按照命令模式的思路设计，把Editor降级为纯Receiver，只提供原子操作，所有业务动作都改成命令类完成。
6.2 核心命令类实例
插入图片命令就是典型例子。它不只是一个insertText，还涉及资源加载、压缩、引用计数：
class InsertImageCommand : public Command { public: InsertImageCommand(Editor& editor, std::string imagePath) : m_editor(editor), m_path(std::move(imagePath)) {} void execute() override { // 在实际处理中，这里加载图片、创建文档引用 m_imageId = m_editor.addImage(m_path); m_editor.insertImageAtCursor(m_imageId); } void undo() override { m_editor.removeImage(m_imageId); m_editor.moveCursorBeforeLastEdit(); } private: Editor& m_editor; std::string m_path; int m_imageId = -1; };这个类里没有太复杂的业务逻辑，所有图片插入的细节都交给Editor，自己只负责记录插入位置、资源和图片ID。后续如果要支持“图片替换”，我只需要再加一个ReplaceImageCommand，然后复用Editor的removeImage和addImage，完全不需要碰原来已有命令的代码。
6.3 数据一致性维护
由于编辑器的预览是实时渲染的，每次命令执行和撤销都会触发重绘。一开始我直接在undo里调用m_editor.refreshView()，导致撤销一批命令时视图刷新了好多次，性能明显变差。
后面我把视图刷新移到了Invoker层面：在批量执行前先冻结渲染，所有命令执行完再统一刷新一次。这个优化虽然看着简单，但体验提升非常明显，尤其是处理大文档时操作延迟降了一个量级——这个改动也证明Invoker的职责可以做得更宽，它不仅调用命令，还能承担“组合执行的调度器”角色。
7. 常见问题速查表——排查实录
我在社区答疑时经常碰到下面这些问题，不少人折腾很久找不到原因。直接整理成一个速查表方便对照：
| 现象 | 根因 | 处理建议 |
|---|---|---|
| 撤销后数据错乱 | 命令对象里保存了指针/引用，但目标对象已释放 | 在命令里存值（拷贝或移动），避免存引用 |
| 重做栈表现诡异 | 新命令执行后没有清空redo栈 | 保持“新操作清空redo”的编辑器标准行为 |
| 执行命令后崩溃 | lambda捕获了临时对象 | 检查捕获列表，确保生命周期长于历史栈 |
| 大命令集合卡顿 | 每条命令都触发重绘 | 用Invoker做批量调度，统一刷新 |
| 撤销顺序错乱 | 复合命令正序恢复 | 必须逆序撤销，与执行顺序严格对称 |
| 内存泄漏 | 裸指针管理命令对象，delete遗漏 | 全部改为unique_ptr，所有权交给Invoker |
| 命令执行了一半抛异常 | execute中业务逻辑出错 | 要么翻译为错误码，要么执行后立即做rollback |
8. 拓展玩法：命令模式还能这么用
8.1 操作队列与异步执行
命令模式天然适配队列化处理。你可以把所有命令对象扔进一个线程安全的队列，然后由后台线程逐个消费执行。这样UI主线程只需要投递命令，耗时操作在后台完成，界面不会卡死。
C++里用std::async或者线程池都能实现。等队列消费完，再把结果通过回调或者future带回来。这个结构和“任务系统”几乎完全一样，命令对象本身就承载了参数和逻辑，编排起来比裸函数指针优雅得多。
8.2 事务与回滚
在数据库或文件系统操作层，命令模式经常和服务一起用：一条业务事务由多条命令组合而成，任何一条失败就整体回滚，全部成功才提交。这其实就是“复合命令 + 反向操作”的组合应用。业务事务本质上就是一个高级的CompoundCommand，只是多了一个事务上下文。
这个思路尤其适合C++后端开发，比如配置管理服务、批量同步工具。用命令模式组织事务逻辑之后，每个步骤的可测试性极佳——你不需要跑完整事务，单独测某条命令的execute和undo就行。
8.3 日志与审计
每个命令在execute时写一条审计日志，记录操作人、操作内容、操作时间，这个实现成本极低，因为日志逻辑完全可以放在Invoker里，不用污染具体命令类。设想一个财务系统，所有操作都命令化之后，审计模块基本上就是给Invoker挂一个listener，命令详情自动记录，根本不需要改动业务代码。
说句真心话，命令模式是GoF那些模式里，我实际用到最多的一个。它不像单例那样被滥用，也不像工厂那样到处都是，但它解决的“请求的生成与执行分离”这个问题，几乎是所有交互型软件永远绕不过去的。
用C++实现时，把RAII、unique_ptr、lambda、类型擦除这些现代特性用好，整个模式写起来比十几年前的教科书自然得多。加上测试也方便——每条命令的execute和undo都可以单独对待，测清楚一个类，全局撤销系统就可信了。
