关键在于将用户操作封装为可存储、可调用、可倒带的命令对象，其必须自带执行前状态并提供对称的execute()和undo()方法；需在执行前主动捕获并持久化原始数据，而非撤销时现场读取；接收者仅提供原子方法，不参与历史管理；撤销重做通过undostack与redostack双栈协作实现，新命令清空redostack，不可逆操作需预存快照或设计补偿逻辑。
关键在于把“用户做了什么”变成一个能存、能调、能倒带的对象，而不是直接调用方法。命令对象必须自己持有执行前的状态，并提供对称的 execute() 和 undo() 方法。
命令对象要自己保存快照，不能现场读取
撤销不是靠“反向猜”，而是靠“原样还原”。比如插入文本，不能在 undo 里去读当前编辑器内容再删掉；而要在 execute 前就保存原始文本片段或光标位置等关键字段。
- 构造命令时传入原始值：如 new InsertTextCommand(editor, "hello", 5, editor.getText())
- 或在 execute 开头主动捕获：如 this.prevText = receiver.getText()，并作为字段长期持有
- 避免 undo 中调用 receiver.getCurrentState()——UI重建、异步刷新后该值可能已失效
接收者只干活，不参与撤销逻辑
接收者（如 Document、Player、Light）只暴露原子业务方法（save()、jump()、setColor()），它完全不知道自己被哪个命令调用，也不保存历史状态。
- 所有状态管理、条件判断、参数组装都由命令类完成
- 接收者方法应是幂等或可重入的，便于重做时再次调用
- 若操作涉及多个接收者，命令类负责协调顺序与事务边界
用双栈管理历史，统一调度执行流程
撤销重做不是单个列表来回跳，而是两个独立栈协作：undoStack 存已执行命令，redoStack 存刚被 undo 的命令。
- 新命令执行后：push 到 undoStack，同时清空 redoStack
- 点击撤销：pop undoStack → 调用 undo() → push 到 redoStack
- 点击重做：pop redoStack → 调用 execute() → push 回 undoStack
- 栈中建议存弱引用或纯数据对象，避免强持 UI 控件导致内存泄漏
对不可逆操作提前设计补偿逻辑
文件保存、网络请求、数据库提交这类操作无法自然回退，不能依赖 undo() 反向调用。
- 预存快照：如保存前先读取文件原始字节并缓存
- 引入补偿命令：如 “发送邮件” 对应 “撤回邮件” 或 “发更正通知” 命令
- 标记是否可撤销：isUndoable() 方法供 Invoker 过滤，避免无效入栈
