备忘录模式的核心结构怎么搭
关键不是“存状态”，而是隔离状态存储与业务逻辑。必须有三个角色：
Memento（只读快照）、
Originator（被备份的对象，能创建和恢复自身状态）、
Caretaker（保管
Memento，但不能访问其内容）。C# 里最容易错的是把
Memento设成 public 字段或属性——这会破坏封装，让外部随意修改快照。
实操建议：
Memento类必须是
private嵌套类或
internal类，构造函数接收
Originator的内部状态，仅提供只读属性（如
public string State { get; }）
Originator提供两个方法：
CreateMemento()返回新快照，
SetMemento(Memento m)从快照恢复；注意不要在
SetMemento中直接赋值字段，而应调用私有恢复逻辑
Caretaker只持有
Stack<memento></memento>或
List<memento></memento>，不碰
Memento内部字段
撤销/恢复操作怎么支持多步和重做
单步
Undo很简单，但真实场景需要历史栈 + 重做栈。如果只用一个
Stack<memento></memento>，执行
Undo后再修改对象，旧的“重做点”就丢了。
实操建议：
维护两个栈：private readonly Stack<memento> _undoStack = new();</memento>和
private readonly Stack<memento> _redoStack = new();</memento>每次修改前调用
_undoStack.Push(originator.CreateMemento())，同时清空
_redoStack（因为新操作使重做失效）
Undo()弹出
_undoStack顶部，恢复后把原快照压入
_redoStack；
Redo()则反向操作 注意：如果对象很大，频繁深拷贝状态会吃内存，可考虑用差分快照或只存变更字段（需额外元数据支持）
如何避免序列化导致的性能和兼容性问题
有人直接用
JsonSerializer.Serialize(originator)存整个对象——这看似省事，但实际埋雷：版本升级后字段名改了、新增了不可序列化成员、或者
DateTime时区处理不一致，都会让旧快照无法恢复。
实操建议：
绝不依赖自动序列化存Memento；显式定义快照结构，例如
public record TextEditorState(string Content, int CaretPosition)在
Originator中用
private字段存状态，
CreateMemento()只提取必要字段构造轻量
Memento，不暴露实现细节 如果状态含复杂引用类型（如自定义集合），确保
Memento中存储的是深拷贝值（用
new List<t>(originalList)</t>而非直接引用） 避免在
Memento中存
Action、
Delegate或未标记
[Serializable]的类型——它们无法跨进程或持久化
UI 层触发撤销时常见线程和生命周期陷阱
WinForms/WPF 中点击“撤销”按钮，常遇到
InvalidOperationException：“集合已修改；枚举操作可能无法执行”，本质是 UI 线程在遍历绑定集合时，
Undo修改了同一集合。
实操建议：
所有涉及 UI 更新的状态恢复，必须封送到 UI 线程执行：Application.Current.Dispatcher.Invoke(() => originator.SetMemento(m))（WPF）或
this.Invoke((MethodInvoker)delegate { originator.SetMemento(m); })（WinForms）
Caretaker不应持有对 UI 控件的引用；状态恢复逻辑全在
Originator内部，UI 层只负责调用
Undo()并响应
PropertyChanged事件 如果
Originator是 ViewModel，记得在
SetMemento后手动调用
OnPropertyChanged触发绑定更新，别依赖自动通知
最易被忽略的一点：备忘录不是免费的。每存一次快照，就是一次状态复制。高频操作（如实时输入）下，要加节流——比如只在用户停顿 300ms 后才存快照，或限制栈深度（
if (_undoStack.Count > 50) _undoStack.Pop();）。
