command接口必须定义execute()和undo()方法，命令对象需保存执行前状态；撤销/重做用双栈管理，防内存泄漏需弱引用或剥离ui依赖；wpf/winforms需结合viewmodel或commandmanager封装；不可逆操作应规避或伪可逆处理。
Command 接口怎么定义才支持撤销和重做
关键不是“实现 ICommand”，而是接口必须包含 Execute()、Undo() 两个方法，且命令对象得能保存执行前的状态（或反向操作所需数据）。常见错误是只实现 Execute()，或者把状态存在 UI 控件里——一旦控件重建，Undo() 就失效。
实操建议：
- 用泛型基类封装公共逻辑，比如
class BaseCommand<tstate> : ICommand</tstate>，让子类专注处理TState的快照与还原 - 避免在
Execute()中直接修改 UI 控件属性；改用数据模型驱动，命令只操作模型，再由绑定机制更新视图 - 如果操作涉及异步（如文件保存），
Undo()不能简单“倒放”，得预存原始内容，而不是依赖当前磁盘状态
如何管理命令历史栈并防止内存泄漏
撤销/重做本质是两个栈：undoStack 存已执行的命令，redoStack 存刚被 Undo() 推出的命令。容易踩的坑是命令对象强引用了窗体、控件或大对象（如图像、文档全文），导致整个页面无法 GC。
实操建议：
- 用
WeakReference包装对 UI 对象的引用（仅当必须时），或彻底剥离 UI 依赖，靠事件或回调通知界面刷新 - 限制栈大小，例如只保留最近 100 条命令：
if (undoStack.Count > 100) undoStack.RemoveAt(0) - 每次
Execute()后清空redoStack——用户新操作意味着“重做”历史失效，这是多数人忽略的语义细节
WPF 或 WinForms 里怎么把按钮点击转成 Command 实例
不是绑 ICommand 就完事。WPF 的 Button.Command 属性只支持 ICommand，但默认不触发 Undo()；WinForms 更没原生支持，得手动 hook Click 事件。
实操建议：
- WPF 中，别直接 new 命令实例塞给 Button；用 ViewModel 暴露
ICommand属性，并在CanExecute里检查是否允许执行（比如文本未变就不该记录命令） - WinForms 中，统一用一个
CommandManager类接收所有操作请求，再分发为具体命令对象，避免每个按钮都 new 一堆匿名委托 - 命令构造时传入必要参数（如被编辑的
TextBox引用或其Text初始值），但别传this或窗体实例——这是内存泄漏高发区
为什么某些操作没法可靠 Undo：典型场景与对策
不是所有操作都适合命令模式。比如调用第三方 SDK 的 SaveToCloudAsync()，它没有“撤回云端保存”能力；又比如随机数生成、时间戳写入、网络请求响应等不可逆行为。
实操建议：
- 对不可逆操作，要么不进命令栈（如日志上报），要么包装成“伪可逆”——例如保存前先本地备份，
Undo()就是恢复本地副本 - 复合操作（如“删除选中行 + 更新总计”）要拆成原子命令，或用
CompositeCommand统一管理子命令的Execute/Undo顺序 - 注意线程上下文：WinForms 控件只能在创建线程访问，若命令在后台线程执行
Undo()，会抛InvalidOperationException：“线程间操作无效”
真正难的从来不是写 Execute 和 Undo，而是判断哪些状态值得存、存多少、什么时候该丢弃——这些决策藏在业务逻辑里，没法靠模式自动解决。
