命令模式在c#中实现undo/redo的前提是命令对象能可靠回滚状态、避免内存泄漏、确保绑定刷新与可执行性判断准确；wpf中canexecute不刷新因未触发canexecutechanged事件，undo失效主因是状态快照存于ui控件、强引用ui或异步操作不可逆。
命令模式在 C# 里不是“实现 ICommand 就能 Undo”的事——它真正起作用的前提是：命令对象能回滚到执行前的状态，且不拖垮内存、不卡死绑定、不误判可执行性。
为什么 WPF 的 Button.Command 绑定后 CanExecute 不刷新？
WPF 不会自动监听 ViewModel 属性变化来重查 CanExecute，它只认 CanExecuteChanged 事件是否被触发。
- 别在
CanExecute里读全局变量或静态字段，必须依赖接收者（如_editor.IsModified）或 ViewModel 自身的可通知属性 - 每次影响可执行状态的属性变更后（比如用户输入导致
IsDocumentDirty变为true），必须手动调用CommandManager.InvalidateRequerySuggested() - 如果用了第三方 MVVM 框架（如 Prism 或 CommunityToolkit.Mvvm），检查是否启用了
NotifyCanExecuteChanged自动机制；没启用就等于没写 - 避免在
CanExecute中做 IO、网络或锁操作——它可能被频繁调用，UI 线程会卡住
Undo() 失效的三个典型原因
不是 Undo() 方法没写，而是它运行时找不到原始数据、引用已释放、或语义错位。
- 状态快照存在 UI 控件里（如直接存
textBox.Text）→ 控件重建后引用失效，Undo()取到 null 或旧值 - 命令构造时传入了强引用的窗体或
UserControl→ GC 不回收，栈越积越大，最终 OOM - 执行了异步操作（如
SaveToCloudAsync()）后，在Undo()里试图“删掉云上文件”→ 实际没有反向 API，只能 UI 回滚，但用户以为真撤销了 - 正确做法：用不可变结构保存关键状态（如
string、int、ImmutableArray<t></t>），或在Execute()前深拷贝接收者关键字段
如何安全地管理 undo/redo 栈而不泄漏内存？
双栈本身很简单，但命令对象若持有大对象或 UI 引用，就会让整个页面无法释放。
- 栈大小必须限制：例如
if (undoStack.Count > 100) undoStack.RemoveAt(0)，否则用户编辑一小时后关窗口，GC 仍要遍历上千个命令 - 对 UI 元素的引用一律用
WeakReference<textbox></textbox>包装，仅当需要聚焦或滚动时尝试TryGetTarget(out var tb) - 每次调用
Execute()后，必须清空redoStack——这是多数人忽略的语义：新操作意味着重做历史作废 - 避免在命令里 new 接收者（如
new Document()）：接收者应由构造函数注入，确保Undo()操作的是同一个实例
哪些操作根本不该进命令栈？
强行给不可逆行为加 Undo()，只会制造幻觉和维护陷阱。
-
SendEmailAsync()、ChargeCreditCard()、LogToExternalService()→ 这些没有配套反向接口，Undo 只能是“假装没发”，实际状态已外泄 -
DateTime.Now、Guid.NewGuid()、Random.Next()→ 结果不可重现，命令里只能存生成后的值，不能“撤销生成动作” - 纯副作用操作（如埋点上报、性能计时结束）→ 应从命令主干剥离，走事件总线或 AOP 拦截
- 如果某个操作只有“执行”意义，没有明确业务级反向含义（比如“切换深色主题”有反向，“播放背景音乐”没有），就别塞进 undo 栈
最常被跳过的细节是：命令对象的生命周期必须和它所操作的数据一致。一个 DeleteRowCommand 如果引用着早已被 Dispose() 的 DataTable，那 Undo() 执行时抛出 ObjectDisposedException 就不是意外，而是设计必然。
