命令模式的核心是将操作封装为具备对称 execute() 和 undo() 方法的对象，二者须幂等互逆、无外部依赖，且命令应无状态、用弱引用避免循环引用，撤销重做通过主栈与缓冲区协同实现。
命令模式的核心：把操作封装成对象
命令模式不是语法糖，而是把“调用动作”变成可存储、可传递、可回放的对象。关键不在继承或接口，而在每个命令类必须同时实现 execute() 和 undo() ——且二者语义对称。比如 TextEditor 的插入操作，execute() 往字符串里加文本，undo() 就得精确删掉那部分，不能只靠全局状态快照。
常见错误是把 undo() 写成“恢复上一个状态”，结果发现状态太多、内存爆炸，或者中间有异步操作导致时序错乱。真正轻量的做法是让每个命令自己记住必要上下文：插入位置、被删内容、旧值……而不是依赖外部状态管理器。
-
execute()和undo()必须是幂等的逆操作，不能依赖外部变量临时存值 - 命令对象应尽量无状态——所有必要数据在构造时传入并固化（如
InsertCommand(editor, text, pos)） - 避免在命令里直接调用
print()或发网络请求；副作用应由接收者（Receiver）承担，命令只负责调度
撤销与重做的栈结构怎么设计才不丢操作
撤销（undo）和重做（redo）不是两个独立栈，而是一个“主栈 + 重做缓冲区”的配合。每次 execute() 后，命令压入 undo_stack，同时清空 redo_stack；每次 undo()，弹出一个命令执行其 undo()，再压入 redo_stack；redo() 则从 redo_stack 弹出并 execute()。
容易踩的坑是把 redo_stack 设计成队列或搞错压栈时机。例如用户连续 undo 三次后执行新命令，这时必须丢弃所有已存的 redo 命令——否则会重做到过期状态。Python 中用 list 模拟栈最直接：undo_stack = []，redo_stack = []，别用 collections.deque 增加复杂度。
- 新命令执行前，先
redo_stack.clear() -
undo()后立即把命令对象 append 到redo_stack，不是复制或序列化 - 栈为空时调用
undo()或redo()应静默失败（不抛异常），或返回布尔值表示是否成功
Python里怎么避免命令对象循环引用导致内存泄漏
命令对象常持有一个接收者引用（如 self.receiver = editor），而接收者又可能持有命令历史栈——这就构成循环引用。CPython 的引用计数能处理，但带 __del__() 或弱引用的场景下会出问题，尤其在测试中反复创建销毁编辑器时，gc.collect() 都不一定及时回收。
解法很简单：用 weakref.ref 存接收者。命令执行时先检查引用是否还有效，无效则跳过；undo() 同理。这样命令对象本身不增加接收者的引用计数，破环就自然解了。
- 构造时写
self._receiver_ref = weakref.ref(receiver)，不用self.receiver = receiver - 在
execute()开头加receiver = self._receiver_ref()，然后if receiver is None: return - 不要在命令里绑定 lambda 或闭包捕获接收者，那会隐式强引用
实际项目中哪些操作不适合做成命令
不是所有函数调用都该塞进命令模式。像日志记录、指标上报、缓存更新这类旁路操作，没有明确的逆操作，硬加 undo() 只会让代码变脆。还有纯计算型操作（如格式转换、数值归一化），本身无副作用，也无需撤销。
真正适合命令模式的是：改变可观察状态、用户显式触发、需要原子性控制的操作。典型如文件保存（SaveCommand 要处理失败回滚）、图形移动（记录旧坐标）、批量删除（缓存被删 ID 列表）。
- 涉及 I/O 的命令必须考虑失败路径：
execute()失败时，不能把命令推入 undo 栈 - 耗时操作（如导出大文件）不适合同步命令，应拆出任务队列，命令只负责提交任务
- 数据库事务类操作，命令应封装为“事务单元”，
undo()对应ROLLBACK，而非反向 SQL
命令模式的价值不在结构多漂亮，而在让“撤销”这件事变得可预测。只要 undo() 能稳定回到上一步，且不依赖全局时序，就算落地成功。其余都是细节取舍。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
