备忘录模式的核心是让发起人主动快照状态，通过私有静态内部类Memento封装只读数据，管理者仅作引用存储与传递，不解析内容；需深拷贝、防反射、限数量、过滤敏感信息。

关键在于把状态保存这件事“交还给对象自己”，而不是让外部强行读取字段。备忘录模式不是靠暴露属性来备份，而是靠对象主动快照、封装存储、定向恢复。

发起人（Originator）负责状态的自我快照

发起人是拥有状态的对象，比如一个编辑器、游戏角色或配置管理器。它内部定义创建和恢复方法，例如 createMemento() 和 restore(Memento)。这些方法能直接访问私有字段，因此无需对外公开任何状态细节。

• 调用 createMemento() 时，发起人将当前所有关键字段值（如 content、fontSize、hp）复制进一个新的备忘录实例
• 复制必须是深拷贝，尤其对可变引用类型（如 List、Map），避免后续修改影响已存快照
• 备忘录类通常作为发起人的静态内部类，天然限制访问范围，增强封装性

备忘录（Memento）只提供只读窄接口

备忘录本身不承担业务逻辑，只是一个纯粹的状态容器。它的字段全部设为 private final，仅开放 getter 方法供发起人读取——其他任何类（包括管理者）都无法修改或窥探完整结构。

• 外部看不到字段名、类型或数量，只能通过约定好的接口获取有限信息（如时间戳、操作类型等元数据）
• 不提供 setter、不支持序列化暴露、不继承公共基类，防止被意外扩展或反射绕过
• 如果需要多版本兼容，可在备忘录中增加版本号字段，由发起人控制解析逻辑

管理者（Caretaker）只做“保险柜”，不做“解码员”

管理者只持有备忘录的引用（如 Stack<Memento> 或 List<Memento>），完全不依赖其内部结构。它不调用任何可能触发状态变更的方法，也不尝试 instanceof 判断或强制转型。

• 保存时：接收发起人传来的 Memento 实例，原样压栈或入队
• 恢复时：按需取出 Memento，原样交还给发起人，由发起人自行解析并重置自身
• 管理者可以支持撤销/重做栈、带时间索引的历史列表，但所有操作都基于引用传递，不触碰内容

实际编码中的关键细节

以 Java 为例，避免常见陷阱：

• 不要把 Memento 设为 public 类；推荐 static nested class，确保只有 Originator 能构造和访问
• Originator 的 restore() 方法应先校验备忘录是否为空或有效，再逐字段赋值，避免 NPE 或脏数据
• 高频操作场景下，考虑限制备忘录数量（如最多保存 50 条），或采用增量快照+基准快照组合降低内存占用
• 若状态含敏感信息（如 token、密码），应在 createMemento() 中显式过滤，不在备忘录中留存