做编辑器或者游戏功能时大家应该都有过这种经历用户一顿操作猛如虎结果误删了一段重要内容想撤销却发现状态回不去了。这种需求看着简单真做起来却很棘手——你既要把对象某一时刻的内部状态完整保存下来回头还能一键还原又不能为了让外部能访问状态而把封装性拆得稀烂。备忘录模式Memento Pattern就是专门干这个的在不破坏对象封装的前提下把状态快照外包出去需要时再恢复。这篇笔记我会从解决什么问题、设计思路、手写实现到进阶实战完整过一遍适合刚开始啃设计模式、也适合写过基础版本但想搞清楚快照深拷贝和撤销栈细节的同学。1. 备忘录模式到底在解决什么难题1.1 一个典型的翻车现场没有存档功能的日子先回到一个很朴素的场景。我早年做过一个带表单编辑功能的管理后台需求是每次保存前自动记录上一次的数据用户点“撤销编辑”就回退。第一版实现很天真在控制器里把表单对象的所有字段挨个 get 出来存到一个 Map 里回退时再挨个 set 回去。跑起来才发现这方案问题一大堆。首先是字段一变存取的代码就要跟着改今天加了手机号字段明天忘了同步回退直接丢数据。更严重的是表单对象里有几个嵌套的子对象Map 里存的是引用用户改了子对象内容存档里的数据也跟着变了根本起不到“快照”的作用。还有一个糟心点为了能存状态我把本该私有的字段都开了 getter/setter业务层到处能直接改数据几个月后代码烂成一锅粥。这个经历很典型。它说明保存状态这件事难点从来不在于“能不能取到值”而在于三个问题怎么在不破坏封装的前提下拿到内部状态。怎么保证快照不会被后续操作“顺带污染”。怎么把“存”和“恢复”的操作从业务代码里剥离出去。备忘录模式就是围绕这三个问题设计的。1.2 官方定义与核心思想备忘录模式的定义很简短在不破坏封装性的前提下捕获一个对象的内部状态并在该对象之外保存这个状态之后可以将对象恢复到原先保存的状态。这里的关键词是“不破坏封装”。翻译成人话就是外部代码只知道“我存了个档”“我读了个档”但完全不需要知道存档内部到底有哪些字段、字段间什么关系。真正制作快照的动作必须由对象自己完成因为它最清楚自己的状态边界在哪里。用生活化的话说这就像你去拍照办证件照。拍照师傅发起人负责摆姿势、按快门输出一张照片照片本身备忘录承载了你那一刻的样子而相册管理者负责保存照片但它不关心照片里是谁只管存和取。下次你需要换证件照拿着照片回去冲印就行。从名字也能看出来这个模式的核心是“备忘”二字把容易忘记、容易丢失的状态记录下来给自己留一条后路。1.3 三个角色的分工发起人、备忘录、管理者备忘录模式一共就三个角色职责边界非常清晰。我用一张表整理一下角色类名习惯核心职责关键约束发起人 OriginatorGameCharacter / TextEditor / Order持有业务状态负责生成备忘录负责从备忘录恢复状态生成和恢复的逻辑必须写在发起人内部备忘录 MementoGameStateMemento / EditorSnapshot保存发起人在某一时刻的状态快照对外只读尽量不可变不能给外部暴露修改入口管理者 CareTakerGameArchiveManager / HistoryStack保存备忘录对象决定何时存、何时取、保留多少份不读、不改备忘录的内部数据很多初学者搞混管理者和备忘录的边界觉得管理者就是“备忘录的集合”这是对的但有一个重要补充管理者应该完全不了解备忘录的内部结构。它只做三件事——存、取、判空。这种拆分的好处很明显。发起人不需要关心“我的存档存在哪里、存了几份”管理者不需要关心“这个存档里到底有什么”外部调用方只需要面对管理者不用和快照的具体实现打交道。三层各管各的改任何一层都不太会波及其他层。2. 设计拆解为什么备忘录模式长这样2.1 封装悖论状态要保存但不许外部乱摸备忘录模式设计里最微妙的地方在于它要解决一个看似矛盾的需求一方面状态快照必须能被“对象之外”的代码长期持有另一方面持有方又不能直接修改快照内容。如果直接把发起人的私有字段全部暴露出去表面上是方便了实际上等于把防御全拆了。任何一个调用方都能手滑把存档里的数值改掉回头恢复出来的状态就是错的。所以备忘录模式的做法是状态快照由发起人自己创建创建完成后快照对外只读谁也别想改。你可能会想那快照里的字段外部不允许改发起人恢复时怎么读这就引出了备忘录模式特有的接口设计问题称之为“宽窄接口”问题。简单说发起人需要看到快照的所有字段所以它看到的接口是“宽”的管理者只需要保存和取出快照对象不需要看到里面的内容所以它看到的接口是“窄”的。实践中怎么实现宽窄接口分?在 Java 里最干净的做法就是用内部类。备忘录做成发起人的私有内部类发起人天然可以访问它的私有字段而外部代码拿到的只是一个不透明对象想读数据都没入口。不过这种方式在有些语言里不方便或者团队成员不习惯折中方案是备忘录用独立类但只提供 getter、不提供 setter字段全用 final 修饰配合包级私有构造器也能达到类似效果。2.2 备忘录的快照设计不可变性是关键关于备忘录对象的实现我有一条硬经验把快照做成不可变对象这是性价比最高的防御手段。所谓不可变通俗讲就是对象创建完成之后它的所有字段值都不可再被修改。实现起来通常就三板斧所有字段都用 final 修饰。构造时通过构造器一次性传值不提供无参构造。不提供任何 settergetter 返回的是基本类型或不可变对象。为什么要这么较真你看备忘录存在的意义是“忠实记录某一时刻的状态”。如果这个记录本身能被改动那它记录的就不再是那一时刻了整个模式就失去了根基。用一个游戏存档类比你打 Boss 前拍了张“满血满蓝”的照片结果照片被别人拿画笔涂了两笔回头你拿着照片去恢复状态恢复出来个残血角色这存档还有什么意义另外还有个容易被忽略的点getter 返回引用类型时要小心。如果备忘录里有一个 List 字段getter 直接把内部 List 返回出去外部拿到引用就能往里加元素。稳妥的做法是返回时做防御性拷贝或者干脆在备忘录里存不可变的 List 副本。2.3 管理者的存在意义把存档从业务代码里剥离第三个角色管理者看起来只是简单包了一层 List 或 Stack但它承担了一个重要职责把存档的生命周期管理从业务代码里剥离出去。什么意思假设没有管理者这个角色业务代码里就会到处散落着“要不要存、存几份、存了之后什么时候清掉”的逻辑。比如打完一个小怪存一次进入新地图存一次开打 Boss 前再存一次然后一旦收到“角色死亡”事件就把这些存档依次翻出来找最近的一份。这些逻辑如果写在游戏主流程里代码会变得很臃肿而且不同场景的存档策略会互相打架。有了管理者业务方只需要告诉它“帮我存一份”“给我最近一份”至于用栈、用列表还是用数据库表管理者内部自己决定。我今天想改成只保留最近 5 份存档只需要动管理者这一个类游戏角色和存档类一行都不用改。2.4 与原型模式、命令模式的底层关系学习备忘录模式时很多人会把它和几个邻居模式搞混这里说清楚区别。原型模式Prototype是通过克隆创建对象副本。它解决的是“拷贝一份对象出来”的问题拷贝完就是两个独立对象了。备忘录模式解决的不是拷贝而是“记录并还原”的问题。两者虽然都用到了“快照”思想但目的完全不同。实践中可以把原型模式当作备忘录的一个实现手段——用 clone 方法生成状态副本存进备忘录但千万别觉得“会 clone 就等于用了备忘录”。命令模式Command记录的是“操作”备忘录记录的是“状态”。两者经常配合使用而且配合起来非常爽。命令模式负责执行一个动作执行前先把当前状态快照存入备忘录执行后要撤销时从备忘录里恢复状态即可。这样既有操作的语义又有状态的回退能力CtrlZ 和 CtrlY 就能做到非常顺滑。这一块后面我用代码详细演示。至于状态模式State它关心的是“行为如何随状态变化”而备忘录关心的是“状态如何保存和恢复”方向完全不一样正常业务里不太容易选错。3. 从零手写一个游戏存档系统3.1 场景设定与需求分析纸上谈兵聊完下面直接手写代码。我选一个最直观的场景游戏角色的存档系统。假设角色有四个状态血量 hp、魔法 mp、等级 level、当前位置 position。业务上有一系列操作受伤、放技能、移动、升级。需求是玩家在进入危险区域前可以手动存档一旦角色残血甚至死亡可以回退到存档时的状态。这个场景足够简单又涵盖了备忘录模式的全部要素。我写的是 Java 版本语言特性上用到了 final、不可变对象、泛型和栈数据结构其他语言的读者也能对照理解。3.2 GameCharacter发起人实现要点拿来写发起人。它负责管理自身状态并且提供两个关键方法saveState 生成快照、restoreState 从快照恢复。public class GameCharacter { private int hp; private int mp; private int level; private String position; public GameCharacter(int hp, int mp, int level, String position) { this.hp hp; this.mp mp; this.level level; this.position position; } public void takeDamage(int damage) { this.hp Math.max(0, this.hp - damage); } public void useSkill(int cost) { this.mp Math.max(0, this.mp - cost); } public void move(String newPosition) { this.position newPosition; } public void levelUp() { this.level; this.hp 100; this.mp 50; } public GameStateMemento saveState() { return new GameStateMemento(hp, mp, level, position); } public void restoreState(GameStateMemento memento) { if (memento null) { throw new IllegalArgumentException(存档不能为空); } this.hp memento.getHp(); this.mp memento.getMp(); this.level memento.getLevel(); this.position memento.getPosition(); } Override public String toString() { return GameCharacter{hp hp , mp mp , level level , position position }; } }注意两个细节。第一saveState 里创建快照时直接把当前字段值传进去这个动作必须由发起人自己完成不能让外部传参进来拼装快照否则又回到“外部过度介入内部状态”的泥潭。第二restoreState 开头做了空值校验不校验的话一旦管理者没有存档却调用了恢复就会出现空指针而且这种 bug 很难排查。3.3 GameStateMemento备忘录实现要点接着看备忘录类的写法。public class GameStateMemento { private final int hp; private final int mp; private final int level; private final String position; public GameStateMemento(int hp, int mp, int level, String position) { this.hp hp; this.mp mp; this.level level; this.position position; } public int getHp() { return hp; } public int getMp() { return mp; } public int getLevel() { return level; } public String getPosition() { return position; } }这个类看起来就是个普通的数据类但它的重点全在“克制”上。字段全部 final构造器一次性赋值只有 getter 没有任何 setter。这样一来无论谁拿到这个备忘录对象都只能读、不能改。这就是 2.2 里说的不可变快照配合上发起人恢复时自己拉取数据整个链路里没有任何一个环节能意外篡改存档。这里顺带提一个我在代码评审里经常讲的问题备忘录里用了 String 类型的 positionString 本身是不可变的所以 getter 直接返回没问题。如果状态里包含的是 ArrayList、HashMap、Date 这类可变对象就必须做防御性拷贝否则不可变就破了。具体怎么处理我放到第 4 部分的深拷贝陷阱里详细讲。3.4 GameCareTaker管理者实现要点管理者的实现就非常简单了它本质上是个“存档仓库”。import java.util.Stack; public class GameCareTaker { private final StackGameStateMemento saveStack new Stack(); public void save(GameStateMemento memento) { saveStack.push(memento); } public GameStateMemento undo() { if (saveStack.isEmpty()) { throw new IllegalStateException(没有可恢复的存档); } return saveStack.pop(); } public int getSaveCount() { return saveStack.size(); } }我用 Stack 作为存储结构因为游戏存档天然适合“后进先出”——玩家最近一次存的档应该最先被恢复。这里管理者完全不需要知道 GameStateMemento 内部有哪些字段它只管 push 和 pop。这就是职责分离的意义万一某天我想改成只保留最近 10 份存档或者把存档落盘到数据库只需要改这一个类。3.5 运行流程与输出演示把三个类组装起来跑一遍完整流程。public class MementoDemo { public static void main(String[] args) { GameCharacter character new GameCharacter(1000, 500, 10, 新手村); GameCareTaker careTaker new GameCareTaker(); System.out.println(初始状态 character); careTaker.save(character.saveState()); character.takeDamage(300); character.useSkill(80); System.out.println(打完小怪后 character); careTaker.save(character.saveState()); character.move(暗黑森林); character.takeDamage(500); System.out.println(进入危险区域后 character); careTaker.save(character.saveState()); character.levelUp(); System.out.println(冒险途中升级 character); character.restoreState(careTaker.undo()); System.out.println(回退到进入危险区域后 character); character.restoreState(careTaker.undo()); System.out.println(回退到打完小怪后 character); } }我模拟了这样一条冒险线角色在新手村存档打完小怪减了血、耗了蓝再存一次然后走进暗黑森林被重创又存一次结果中途升级了但状态并不理想于是连续回退两次。一次回退到进入危险区域后的状态一次回退到打完小怪后的状态。运行输出会是这样的初始状态GameCharacter{hp1000, mp500, level10, position新手村} 打完小怪后GameCharacter{hp700, mp420, level10, position新手村} 进入危险区域后GameCharacter{hp200, mp420, level10, position暗黑森林} 冒险途中升级GameCharacter{hp300, mp470, level11, position暗黑森林} 回退到进入危险区域后GameCharacter{hp200, mp420, level10, position暗黑森林} 回退到打完小怪后GameCharacter{hp700, mp420, level10, position新手村}这个输出验证了核心链路存了三次档按后进先出的顺序回退每次恢复的状态都和当时存档时完全一致。整个过程中除了发起人自己的业务方法以外没有任何代码能直接改动游戏角色的内部字段GamerStateMemento 拿到外部后也没有任何修改的入口。4. 进阶玩法把备忘录模式用到真实业务里4.1 结合命令模式实现完整的撤销重做能力最简单的存档回退只能往一个方向走但真实的编辑类软件要求的是“撤销 重做”。这时候把备忘录模式和命令模式结合起来就成了一个非常顺手的方案。思路是这样的每个操作都是一个命令对象命令在执行前自己保存一个快照备忘录撤销时从命令里取出快照恢复重做时重新执行命令。注意命令保存的必须是“执行前”的状态这样才能准确回到操作发生之前的样子。我写一个极简的文本编辑器例子。// 文本编辑器发起人 public class TextEditor { private final StringBuilder content new StringBuilder(); public void append(String text) { content.append(text); } public EditorSnapshot save() { return new EditorSnapshot(content.toString()); } public void restore(EditorSnapshot snapshot) { content.setLength(0); content.append(snapshot.getContent()); } public String getContent() { return content.toString(); } } // 备忘录编辑快照 public class EditorSnapshot { private final String content; public EditorSnapshot(String content) { this.content content; } public String getContent() { return content; } } // 命令基类 public interface EditCommand { void execute(); void undo(); } // 追加文本命令内含执行前快照 public class AppendCommand implements EditCommand { private final TextEditor editor; private final String textToAppend; private EditorSnapshot snapshotBefore; public AppendCommand(TextEditor editor, String textToAppend) { this.editor editor; this.textToAppend textToAppend; } Override public void execute() { snapshotBefore editor.save(); // 执行前存档 editor.append(textToAppend); } Override public void undo() { if (snapshotBefore ! null) { editor.restore(snapshotBefore); } } }这里的精髓在于快照是在 execute 方法内部、真正修改内容之前取的。不管用户连续追加了多少次文本撤销栈里每一个命令都握着当时执行前的快照pop 出来一个就恢复一步多操作几次就能一步一步退回去。实际项目里我在做某个内部运营系统的批量编辑功能时也用了这套组合用户对一行的多个字段做变更每个变更字段的操作封装成一个命令命令执行前保存行的快照。撤销时不用整行回滚而是精确回滚到某一步之前产品验收时反馈非常好。4.2 深拷贝陷阱为什么存档会“串数据”备忘录模式最常见的一个坑就是快照里的引用类型字段没有做到真正隔离。我早期用这个模式时就被坑过。当时做一个订单对象状态里有一个 List 商品明细。第一版备忘录我图省事直接把 List 的引用存了进去。结果用户改了订单里的商品数量还没点保存我再看一眼“历史快照”发现快照里的商品数量也变了。原因很简单两个对象引用了同一个 List 实例。这个问题的本质是浅拷贝只复制了引用没有复制对象内容。解决方案按场景有三种在备忘录构造器里用拷贝构造器或 clone 方法复制可变引用对象。用序列化实现深拷贝把对象写进字节流再读出来。从源头上把状态字段设计成不可变对象比如用 List.copyOf 生成不可变列表存进快照。第一种适合引用对象结构固定、且实现了拷贝构造器的场景第二种适合结构复杂、或者嵌套层级很深的场景代码写起来最省事但性能开销大第三种最优雅但并不是所有业务对象都能轻易改成不可变。我的经验是判断一个快照是否安全就反问一句——存档之后我对原对象做任何操作会不会影响这份存档会就说明快照里藏了共享的可变引用必须在存入时切干净。4.3 快照膨胀的三种优化思路备忘录模式另一个常被诟病的问题是内存占用。如果业务对象很大又频繁存档内存里有几十份大清早全量快照应用迟早卡死。这里分享三种优化思路我在不同项目里都用过。第一只存增量不存全量。把“初始快照 变更记录”作为存储模型恢复时从初始快照开始重放变更。这个思路和 Git 的 commit 概念很像每一个 commit 不需要保存仓库完整状态只需要保存相对于父提交的差异。适合状态变化频繁、每次变动影响面小的场景。第二限制快照数量。管理者里只保留最近 N 份存档超出就淘汰最老的一份。很多编辑器就是这么干的撤销历史太长就截断防止内存失控。实现起来很简单存的时候判断一下容器大小即可。第三压缩大字段。如果状态里有一个很大的暂存数据快照时可以先做序列化再压缩用空间换时间。我在某次做报表导出工具时历史版本里要记录大 JSON 数据就是用 GZIP 压缩后存入快照内存直接降了七八成。这三种方式不是互斥的可以组合使用。比如“最近 50 份存档用增量存储超过 50 份的全量快照压缩后落盘”这样既有定位精度又能控制内存。4.4 序列化实现的省事方案与边界还有不少项目图省事直接用 Java 序列化来生成快照。方案大致长这样把发起人对象整体序列化成一个字节数组恢复时再从字节数组反序列化出新对象。写起来确实很爽一段代码搞定所有嵌套深拷贝问题。但这里要泼一盆冷水序列化方案有四个边界问题项目里得想清楚再用。性能。大对象序列化非常慢高频操作下不可接受。版本兼容。类结构一改反序列化就可能抛异常需要维护 serialVersionUID。transient 字段会被跳过。你精心加了个 transient 缓存字段结果快照里根本没有它。反序列化不调用构造器。某些依赖构造器校验的状态在恢复时会被绕过。所以我的建议是序列化方案适合原型演示、或者状态对象非常小且本来就要做持久化的场景但不适合作为核心业务里高频率存档的手段。功能正确不等于方案合适边界要心里有数。5. 常见问题与排查技巧实录5.1 高频问题与解决方案速查表在实际用备忘录模式的过程中有几个问题反复出现我整理成了速查表方便你排查时对照。问题现象根本原因解决方案存档后改原对象快照也跟着变浅拷贝快照持有原对象引用深拷贝可变字段或使用不可变对象恢复时抛空指针异常管理者没存过档就调用恢复恢复前判空给出明确异常信息撤销一次回退了好多步每步操作都创建了新快照但没入栈只覆盖了同一个引用每次快照都新建对象并 push 入栈恢复后部分字段没回到旧值恢复方法只恢复了部分字段恢复逻辑里遍历所有状态字段逐一赋值外部代码能修改快照内容备忘录暴露了 setter 或可变引用字段 final 化getter 返回防御性拷贝旧存档反序列化失败类结构变更版本兼容没处理维护 serialVersionUID或改用字段拷贝方案这里面最诡异的其实是第三条。很多人以为“我每次都存了”但代码里复用了一个备忘录对象后台拿同一个引用反复覆盖结果栈里所有元素指向的最终都是同一个快照内容。这种 bug 不容易一眼看出来排查时可以打印快照的 hashCode 或者对象标识对比一下。5.2 踩过几次坑之后我沉淀下来的心得清单结合这些年的项目经验我把备忘录模式的实操心得浓缩成下面几条。第一快照的制作必须封装在发起人内部不要让外部代码去拼装状态。哪怕外部代码能访问到所有字段也不要这么干。发起人自己有朝一日想调整状态结构改动只局限于自己的类里这是模式设计的底线。第二恢复操作也要有防御。空值校验、字段完整性校验、整体恢复失败时回滚到恢复前状态的预案这些都要提前想好。我在做某次数据迁移工具时恢复中途抛异常导致数据处于“半新半旧”状态那次教训给我留下了很深的印象。现在的做法是恢复前先把当前状态暂存一份恢复失败时先用暂存数据救场。第三备忘录对象不要承担业务逻辑。它只负责记录状态不负责计算、不负责校验、不负责触发其他动作。把业务规则塞进备忘录里会让两个职责纠缠在一起后续维护非常难受。第四存档最好带上元信息。我就见过只存状态字段的快照结果运行时就面临一个尴尬有几份存档但完全不知道哪份是什么时候存的。给备忘录增加时间戳、操作人、场景描述这些元信息字段成本极低排查问题时收益却很高。甚至可以在 UI 层直接展示“刚才”“3 分钟前”“昨天”这样的存档标签交互体验也会好很多。第五注意恢复操作的顺序。栈结构是后进先出列表结构可能是先进先出用错容器管理顺序回退出来的状态就会乱套。这个错误很隐蔽因为不仔细看业务表现不出来。推荐在一开始就明确这个场景的“最近一次存档”应该最先被恢复然后选对应结构。6. 写在最后的一点个人体会备忘录模式在 23 种设计模式里算是“小而深”的那一类。单独为一个对象做状态快照代码量不大结构也不复杂但它解决的是封装性和可恢复性这对矛盾。我在实际项目中最大的体会是它单独出现的频率不算高但一旦和命令模式配合就成了实现撤销重做功能的标准答案。很多编辑器的 CtrlZ 背后本质上都是一条“命令对象持有快照”的链路。另一个心得是这个模式特别适合用在需要“心理安全感”的业务场景。比如批量导入数据的预览与回退、长流程草稿箱、表单多步编辑的暂存恢复用户不需要理解底层的快照机制但他们能感受到“操作错了还能退回来”的保险感。对一个面向用户的系统来说这种安全感带来的信任价值往往比代码结构本身更珍贵。如果你打算在自己的项目里引入备忘录模式我建议不要一上来就封装成通用框架。先在一个具体的、确实有回退需求的功能上写一版最朴素的实现跑通以后再观察哪些地方重复了再去提炼共通的存档管理器和快照基类。从具体场景长出来的抽象永远比从设计模式图鉴里抄来的结构更贴合实际。最后再分享一个小技巧给备忘录加一个描述字段每次存档时顺手写一句“这是哪一步操作之前的快照”日后排查撤销问题时你会回来感谢这个决定的。