命令模式在C#中需规避WPF绑定失控、内存泄漏及异步误用等风险：ViewModel应暴露ICommand属性并正确触发CanExecuteChanged；WinForms宜用CommandManager统一分发；不可逆操作（如云保存、随机数）不可强行支持Undo。
命令模式在 C# 里不是“要不要用”的问题，而是“怎么用才不翻车”的问题。它确实能解耦 UI 和业务逻辑、支持 Undo/Redo，但直接照搬教科书代码，十有八九会在 WPF 绑定、内存泄漏、异步操作或第三方调用上卡住。
WPF 中 ICommand 属性必须暴露在 ViewModel 里，别 new 命令塞给 Button
常见错误是写 button.Command = new SaveCommand()，这会导致命令生命周期失控、CanExecute 不刷新、绑定上下文丢失。WPF 的 ICommand 本质是契约，不是工具类。
- ViewModel 必须定义
public ICommand SaveCommand { get; }属性，并在构造时用RelayCommand或自定义ICommand实现初始化 -
CanExecute方法里要检查真实前置条件，比如!string.IsNullOrEmpty(_currentText)，而不是硬写return true - 不要在命令执行中直接更新 UI 控件（如
textBox.Text = "done"），所有状态变更走 ViewModel 属性 +INotifyPropertyChanged - 如果命令需要访问 UI 元素（如获取焦点、滚动到某行），应通过事件或服务注入，而非传入
TextBox实例——后者极易引发内存泄漏
WinForms 用 CommandManager 统一分发，避免按钮级 new 委托
WinForms 没有内置命令绑定机制，但硬写 button1.Click += (s,e) => { ... } 会让撤销栈、批量执行、权限控制变得不可维护。
- 建一个单例
CommandManager类，提供Register(string key, Action action, Func方法canExecute = null) - 按钮点击统一调用
CommandManager.Execute("save")，由 Manager 查找并执行对应命令 - 撤销栈（
Stack）也由 Manager 维护，每个具体命令实现Execute()和Undo()，不依赖外部状态 - 命令构造时只传必要数据：比如
new DeleteRowCommand(rowIndex)，而不是new DeleteRowCommand(this)或new DeleteRowCommand(dataGridView)
哪些操作根本不能 Undo？别强行套命令模式
不是所有“点击就触发”的行为都适合封装成命令。强行加 Undo() 只会让代码更脆弱、测试更难写、用户更困惑。
-
SaveToCloudAsync()没有配套的RevertCloudSave()接口 → 不该进 Undo 栈 -
DateTime.Now、Guid.NewGuid()、Random.Next()这类不可重现操作 → 命令里只能存结果，不能“撤销生成” - 网络请求（如调用支付 SDK）返回成功后，业务上已产生外部状态 → 此时所谓“Undo”只是前端回滚 UI，实际需走补偿事务，不是命令模式职责
- 日志写入、监控上报这类副作用操作 → 应剥离出命令主干，用事件或中间件处理，不参与撤销链
ICommand 实现里最容易漏掉的两个细节
很多人写了 Execute() 就以为完事了，但 WPF 和 MVVM 框架真正依赖的是两个隐性契约：
-
CanExecuteChanged事件必须被正确触发：比如文本框内容变化后，要调用CommandManager.InvalidateRequerySuggested()或手动 raise 该事件，否则按钮不会变灰 -
Undo()方法不能假设“前一步就是自己”：多个命令可能并发执行，撤销栈必须用Stack显式 push/pop，且每个命令的Undo()必须幂等、无副作用 - 异步命令（如
async Task ExecuteAsync()）不能直接实现ICommand，得用AsyncCommand包装或改用TaskCommand类库，否则会阻塞 UI 线程
命令模式真正的复杂点不在结构定义，而在状态一致性边界——什么时候该记录、什么时候不该、谁负责清理、失败后如何对齐。这些没法靠接口和抽象类自动解决，得在每个 ConcreteCommand 里手写判断逻辑。
