备忘录模式的撤销机制本质是“状态快照 + 隔离恢复”，由发起人通过saveToMemento()深拷贝生成只读备忘录、restoreFromMemento()安全恢复，备忘录私有不可变且仅发起人可构造，管理者仅中转存储不涉状态逻辑。

备忘录模式的撤销机制，本质是通过“状态快照 + 隔离恢复”实现变量级回滚，不依赖全局历史栈或反射，关键在于让对象自己掌控状态存取边界。

发起人（Originator）必须亲自管理状态生命周期

变量状态不能由外部直接读写，否则破坏封装性。发起人需提供两个明确方法：

• saveToMemento()：在状态变更前调用，内部执行深拷贝（如 Python 的 copy.deepcopy、Java 的构造新对象、Go 中显式复制切片/map），生成只读备忘录
• restoreFromMemento(memento)：仅从备忘录中提取值并赋给自身字段，不暴露字段名或结构，也不允许外部修改备忘录内容

备忘录（Memento）要真正“不可变”且“不可见”

它不是普通数据容器，而是状态的封闭快照：

• 字段全部私有（Java/C# 用 private final；Go 用小写未导出字段；Python 建议用 _state 约定 + 深拷贝保障）
• 对外只提供 getState() 类方法，且该方法返回值应为不可变类型（如 String、ImmutableList）或副本，避免外部拿到引用后误改快照
• 构造仅限发起人调用（如 Java 包内访问、C++ friend 声明、Go 同包函数），管理者无法构造或篡改

管理者（Caretaker）只做“存取中转”，不碰状态语义

它像一个带索引的保险箱，职责极简：

• 用数组、切片或栈保存多个备忘录（支持多步撤销）
• 提供 push(memento) 和 pop() 或 get(index)，但绝不调用 memento.getState()
• 不校验状态合法性，不合并、不压缩、不序列化——所有业务逻辑仍在发起人内部

回滚时注意变量粒度与一致性

一次撤销应还原所有相关变量，避免部分更新导致状态错乱：

• 例如文本编辑器，不能只还原内容而忽略光标位置；游戏角色不能只还原血量却漏掉技能冷却时间
• 建议将强关联变量打包进同一备忘录（如 EditorMemento(content, cursorPos, selection)）
• 若变量间存在计算依赖（如 total = price × qty），应在发起人内部统一保存原始字段，而非存衍生值