命令模式的核心是将“调用”封装为可存储传递的对象，通过ICommand接口统一抽象操作，实现调用方与接收者的松耦合；命令应仅转发请求给接收者，避免内嵌业务逻辑，并按需支持Undo、参数校验、上下文注入及生命周期管理。
命令模式的核心是把“调用”变成可存储、可传递的对象
在 C# 中，命令模式不是靠语法糖实现的，而是靠接口抽象和对象封装。关键在于定义一个统一的 ICommand 接口，让所有请求（比如保存、撤销、发送邮件）都实现它，从而抹平操作差异。这样你就能把 button.Click += SaveHandler 这类紧耦合逻辑，换成 button.Command = new SaveCommand(document) 这种松耦合结构。
常见错误是直接在 Execute() 里写业务逻辑，导致命令类无法复用或测试；正确做法是让命令只负责“转发”，把具体动作委托给接收者（Receiver）——比如 SaveCommand 持有 Document 实例，Execute() 里只调用 _document.Save()。
ICommand 接口必须包含 Execute 和 Undo（如果需要撤销）
基础命令至少要有 Execute()；支持撤销时，必须同步提供 Undo()，且两者语义要对称。注意：不是所有命令都需要 Undo()，比如“发送短信”这种不可逆操作，接口可以不定义它，或者实现为空——但别抛异常，否则调用方得处处 try-catch。
-
ICommand接口通常不带泛型，避免过度设计；如需传参，用构造函数注入，而不是在Execute(object param)里塞object - 参数应提前验证：比如
DeleteCommand(Guid id)在构造时就检查id != Guid.Empty，而不是等到Execute()才报错 - 若命令依赖外部状态（如当前用户权限），不要在
Execute()里实时查数据库——应在创建命令时把必要上下文（如CurrentUser）作为只读字段传入
使用委托构造命令可快速原型，但不适合复杂场景
对于简单交互（比如按钮点击触发单行逻辑），可用 Action 封装：
public class SimpleCommand : ICommand
{
private readonly Action _execute;
private readonly Action _undo;
<pre class="brush:php;toolbar:false;">public SimpleCommand(Action execute, Action undo = null)
{
_execute = execute;
_undo = undo;
}
public void Execute() => _execute();
public void Undo() => _undo?.Invoke();}
但这类命令无法序列化、不能带状态、难以调试。一旦涉及重做（Redo）、日志记录、权限校验或异步执行，就得退回到完整类实现——比如把 SaveCommand 的 Execute() 改成 async Task ExecuteAsync()，并继承 IAsyncCommand（自定义接口）。
命令队列与 Invoker 是解耦关键，别让 UI 层直接 new Command
真正体现命令模式价值的地方，是把命令的“生成”“调度”“执行”彻底分离。UI 层（如 ViewModel）只负责创建命令实例并交给 Invoker，而 Invoker 管理执行顺序、事务包装、异常兜底。例如：
-
Invoker可以批量执行命令并统一提交数据库事务 - 历史记录功能只需维护一个
Stack<icommand></icommand>，每执行一个就Push()，点撤销就Pop().Undo() - 避免在
Button_Click里直接 newSaveCommand(doc)—— 应通过工厂或 DI 容器获取，否则单元测试时无法 Mock 接收者
最容易被忽略的是命令的生命周期管理：如果命令持有大对象引用（如整个 DataTable），又没及时释放，会引发内存泄漏。建议在 Execute() 后清空敏感字段，或用 IDisposable 显式释放。
