命令模式的核心是将调用封装为对象，解耦调用者与接收者，典型结构含Command接口、具体命令类和接收者；可用std::function+lambda轻量实现，高频场景宜用模板化零开销方案，undo需在execute前保存足够状态快照。
命令模式的核心是把“调用”变成对象
不是写个函数然后调用它，而是把「谁调用、调用什么、传什么参数」全打包进一个类实例里。这样你就能存起来、排队、撤销、重放——关键在于解耦调用者（比如按钮）和接收者（比如文件处理器）。
典型结构包含三部分：Command 抽象接口、具体命令类（如 SaveCommand）、接收者（如 Document）。调用者只依赖 Command，完全不知道背后是保存还是删除。
常见错误是直接在 execute() 里写业务逻辑，导致命令类膨胀且难以复用。正确做法是让命令持有对接收者的引用，并只转发调用。
-
Command接口必须定义execute()（以及可选的undo()） - 具体命令构造时接收
Receiver*和必要参数（如文件路径），不现场获取 - 避免在命令里 new 接收者——接收者应由上层创建并注入，否则破坏控制流
如何用 std::function + lambda 封装成轻量命令对象
C++11 之后，不必硬写一堆继承类。用 std::function<void></void> 包一层 lambda，就能把任意调用转成可存储、可拷贝的命令对象。
立即学习“C++免费学习笔记（深入）”；
比如你想把 document->save("a.txt") 封装成命令：
auto saveCmd = [&document]() { document->save("a.txt"); };但注意：lambda 捕获方式决定生命周期风险。用 [&] 可能悬空；用 [=] 又可能深拷贝大对象。稳妥做法是显式捕获指针或 std::shared_ptr：
- 接收者用
std::shared_ptr<Document>管理，命令中捕获该智能指针 - 参数（如文件名）按值捕获，避免字符串生命周期问题
- 若需 undo，额外存一个
std::function<void></void>回滚操作，不要在execute()里临时构造
带参数的命令怎么避免类型擦除开销
用 std::function 方便，但每次调用有虚函数跳转+内存访问开销。高频场景（如游戏帧循环里的输入命令）要考虑替代方案。
更高效的方式是模板化命令类，把行为和参数类型固化在编译期：
template<typename Receiver, typename... Args>
struct FunctionCommand {
Receiver* receiver;
void (Receiver::*method)(Args...);
std::tuple<Args...> args;
void execute() { std::apply([this](auto&&... xs) { (receiver->*method)(xs...); }, args); }
};这样零运行时开销，但每个不同签名都会生成新类型，不能统一存进 std::vector<std::unique_ptr<Command>>。权衡点很明确：
- 需要统一容器管理 → 用
std::function或虚函数基类 - 极致性能且命令种类固定 → 模板命令 + variant 或手动 dispatch
- 混用场景？先用
std::function快速验证逻辑，热点再重构
为什么 undo/redo 容易出状态不一致
命令对象只管执行，但 undo 要求它“记得自己干了什么”。最常踩的坑是：在 execute() 中修改了接收者状态，却没在命令里存下足够信息来还原。
例如 DeleteCommand 执行时删了一行文本，但没把那行内容存进命令对象——undo 就只能瞎猜。解决方法很实在：
- 所有影响状态的操作，必须在
execute()前把“前状态”拍快照（如字符串、坐标、ID 列表） - 快照数据存在命令对象成员里，别依赖接收者自己记（它可能被多个命令共享）
- 如果接收者本身支持 Memento 模式，命令可以只存 memento 对象，而非原始数据
- 多步命令（如“拖拽+缩放”组合）要确保每步 undo 顺序与 execute 相反，且中间状态不可见
真正麻烦的不是封装动作，而是封装“可逆性”。只要有一处命令没存够上下文，整个 redo 链就断了。
