C++中实现Undo/Redo必须用命令模式封装操作，命令对象需自主管理状态快照或反向逻辑；裸指针、栈存原始Command*、不深拷贝上下文数据会导致崩溃或错乱；应使用std::unique_ptr管理生命周期，execute/undo需成对设计并在执行前捕获完整状态，且CommandManager执行新命令时须清空redoStack。
直接说结论：C++里做 Undo/Redo，**必须用命令模式封装每个可逆操作，且命令对象要管理自己的状态快照或反向逻辑，不能依赖外部实时状态**。裸指针、栈中存原始 Command*、不深拷贝上下文数据——这三类写法上线后必出撤销错乱或崩溃。
为什么 std::stack<:unique_ptr>> 是底线配置
很多初学者用 std::stack<command></command> 存裸指针，以为“反正命令对象是 new 出来的”，但忘了：谁 delete？什么时候 delete？Undo 后 Redo 又执行一次，同一块内存可能被重复 delete 或访问已释放区域。
std::unique_ptr<command></command> 把生命周期和栈绑定，undoStack.pop() 自动析构，redoStack.push(std::move(cmd)) 转移所有权，安全又清晰。
- 不用手动
delete，避免 double-free 或 use-after-free - 移动语义让压栈/出栈零拷贝，性能不打折
- 如果命令需跨线程或异步执行，换成
std::shared_ptr更稳妥
execute() 和 undo() 必须成对设计，且状态捕获要「执行前」完成
典型错误：在 execute() 里改了接收者状态，然后在 undo() 里“猜”怎么还原——比如删文本时只记了位置，没记删了什么内容，undo 就只能瞎填。
正确做法是在命令构造或 execute() 开头就捕获必要快照：
-
DeleteCommand：构造时传入document.getContent().substr(pos, len)，不是只存pos和len -
MoveObjectCommand：保存移动前的x、y，而不是靠接收者当前坐标反推 - 所有字符串、vector、自定义结构体，用值语义（
std::string、std::vector<int></int>）而非引用或指针
CommandManager 的 redoStack 清空时机很关键
用户执行新命令后，再按 Ctrl+Z，应该只能 Undo 到最新一步；但如果这时点了 Ctrl+Y（Redo），却把很久以前的命令翻出来重放，说明 redoStack 没清干净。
标准行为是：每次调用 executeCommand()，必须清空 redoStack。
- 错误写法：
redoStack.clear()放在undo()里 —— 这会导致连续 Undo 后无法 Redo - 正确位置：在
executeCommand()入口，undoStack.push()前执行redoStack = std::stack<:unique_ptr>>()</:unique_ptr> - 更健壮的做法：用
std::deque替代双栈，用下标游标管理历史位置，避免栈拷贝开销（适合高频操作场景）
撤销链断裂往往源于接收者生命周期失控
命令对象里存了 Receiver* 或 Document&，结果接收者提前析构，Undo 时一调用就 crash。
有三个实际可用方案：
- 接收者用
std::shared_ptr管理，命令里也持std::weak_ptr，execute()开头用lock()检查是否还活着 - 命令不存接收者指针，改用回调函数（
std::function<void></void>），由 Client 注入执行逻辑 - 最简单但有效：约定接收者生命周期 ≥ CommandManager，靠文档和代码审查守住这条线（适合小型工具）
真正难的不是写完 undo()，而是确保它在任意时刻被调用都不会访问悬垂指针或已释放内存——这点在多线程或异步撤销时尤其容易被忽略。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
