前言
为什么需要备忘录模式？
假设正在做一个文本编辑器，需要支持 Ctrl+Z 撤销功能。最直觉的写法是每次修改前把整个 Editor 对象的内部字段抄一份出来放到栈里：

class Editor {
public String content; // 为了保存历史，只能开放成 public
public int cursorPos;
public String selection;
}

class History {
private Deque<Object[]> snapshots = new ArrayDeque<>();

public void save(Editor editor) { // 直接读取 editor 的内部字段 snapshots.push(new Object[]{editor.content, editor.cursorPos, editor.selection}); } public void undo(Editor editor) { Object[] snap = snapshots.pop(); editor.content = (String) snap[0]; editor.cursorPos = (int) snap[1]; editor.selection = (String) snap[2]; }

}
这种写法有两个致命问题。第一，Editor 内部所有字段被迫暴露成 public，封装性荡然无存——任何人都能随意修改编辑器内部状态。第二，一旦 Editor 新增或删除字段，History 的保存/恢复代码都得跟着改，两个类死死绑定。

我之前一直以为撤销就是"把变量拷一份存起来"，后来才明白：真正的问题不是拷贝本身，而是谁能看到快照里存了什么。历史管理者只需要"保管"快照，不需要"理解"快照。备忘录模式解决的就是这个问题——让状态既能被保存，又不破坏对象的封装边界。

概念
备忘录模式（Memento Pattern）也叫快照（Snapshot）模式，是一种行为型设计模式，核心思想是在不破坏封装性的前提下，捕获一个对象的内部状态，并将该状态保存到对象外部，以便之后能将对象恢复到先前的状态。

可以把它想象成银行保险箱：储户（发起人）把重要物品装进保险箱（备忘录）后交给银行（管理者）保管，银行只知道自己保管着一个箱子，但没有钥匙打不开——只有储户本人能打开取出物品。银行负责调度箱子（存进哪个格子、什么时候取出），但永远不知道箱子里装了什么。

备忘录模式涉及三个角色：

Originator（发起人）：需要保存和恢复状态的对象，负责创建 Memento（记录当前状态）和使用 Memento（恢复历史状态）
Memento（备忘录）：存储发起人内部状态的快照对象，对发起人提供宽接口（完整读写），对外部提供窄接口（只能传递，不能查看/修改）
Caretaker（管理者）：负责保管备忘录，但永远不操作或查看备忘录的内容，职责仅限于"拿着"和"递回去"
创建并读取

保管

通知保存/恢复

Originator

-state: String

+setState(state: String)

+getState() : String

+createMemento() : Memento

+restoreFromMemento(m: Memento)

Memento

-state: String

-Memento(state: String)

-getState() : String

Caretaker

-history: Deque

+save(o: Originator)

+undo(o: Originator)

图中各类之间的关系：Originator 创建 Memento 并能读取其内部状态，Caretaker 只持有 Memento 的引用但不能访问其字段（构造器和 getter 都是私有的），Caretaker 通过调用 Originator 的 createMemento 和 restoreFromMemento 方法完成保存与恢复——Memento 的内容始终对 Caretaker 不透明。

实现
GoF 原书用的是双接口方案：Memento 同时暴露两套接口——对 Originator 提供宽接口（能读写完整状态），对 Caretaker 提供窄接口（一个几乎是空的接口，只有标识信息，不能查看内容，原书把它命名为 MementoIF）。Caretaker 只持有这个窄接口类型，因此在编译期就调不出任何读写状态的方法；Originator 拿回来时再强转成宽类型，恢复完整能力。这套方案用接口隔离来实现"发起人能看、管理者看不到"。

在 Java 中更自然的落地方式是内部类——把 Memento 作为 Originator 的静态内部类，用访问控制替代接口隔离。Originator 作为外部类可以访问内部类的所有私有成员，而外部（包括 Caretaker）只能声明 Memento 类型的变量，无法调用其私有构造器和私有 getter。两者效果相同（发起人可读写、管理者不可见），但机制不同：一个靠接口类型隔离，一个靠成员访问控制。这样天然模拟了 C++ 中 friend 机制的效果，下文示例都采用这种方式。

基础实现
定义 Originator 类，内部持有 state 字段，并提供 createMemento（创建快照）和 restoreFromMemento（恢复快照）方法。Memento 作为 Originator 的静态内部类，构造器和 getter 均为 private——只有 Originator 能创建和读取。Caretaker 用 Deque<Originator.Memento> 保存历史快照，能引用 Memento 类型但看不到其内部状态。

需要说明的是，真正的封装靠的是成员 private（构造器和 getter 都不对外开放），而不是类本身的可见性。Memento 类可以是包级私有（default，防止其他包直接引用），也可以是 public——只要成员是 private，Caretaker 就只能"持有"却无法"打开"。

// Originator：发起人
class Originator {
private String state;

public void setState(String state) { this.state = state; } public String getState() { return state; } // 创建备忘录：只有自己能构造 Memento public Memento createMemento() { return new Memento(state); } // 恢复状态：只有自己能读取 Memento 的私有字段 public void restoreFromMemento(Memento memento) { this.state = memento.getState(); } // Memento：备忘录（静态内部类） static class Memento { private final String state; private Memento(String state) { // 私有构造：只有 Originator 能创建 this.state = state; } private String getState() { // 私有 getter：只有 Originator 能读取 return state; } }

}

// Caretaker：管理者
class Caretaker {
private final Deque<Originator.Memento> history = new ArrayDeque<>();

public void save(Originator originator) { history.push(originator.createMemento()); } public void undo(Originator originator) { if (!history.isEmpty()) { originator.restoreFromMemento(history.pop()); } }

}
角色对照：

Originator（发起人）：Originator，持有 state，提供 createMemento 和 restoreFromMemento
Memento（备忘录）：Originator.Memento 静态内部类，构造器和 getter 均为 private
Caretaker（管理者）：Caretaker，持有 Deque<Originator.Memento>，负责保存和取出快照
关键点：Caretaker 能声明 Originator.Memento 类型的变量并保存到栈里，但既不能自己构造它，也不能读取它的 state 字段——Memento 对它是完全不透明的。Originator 作为外部类，可以自由访问内部类的所有私有成员，这是 Java 内部类的特权。

引入一个具体场景：文本编辑器的撤销/重做功能。用户每次编辑前先保存快照，Ctrl+Z 恢复上一个快照，Ctrl+Y 重做被撤销的操作。编辑器的内部内容不应该被历史管理器直接访问。

// Originator：文本编辑器
class TextEditor {
private StringBuilder content = new StringBuilder();

public void write(String text) { content.append(text); } public void deleteLast(int n) { int start = Math.max(0, content.length() - n); content.delete(start, content.length()); } public String getContent() { return content.toString(); } // 创建快照 public Snapshot save() { return new Snapshot(content.toString()); } // 恢复快照 public void restore(Snapshot snapshot) { content = new StringBuilder(snapshot.getContent()); } // Memento：编辑器快照（内部类） static class Snapshot { private final String content; private Snapshot(String content) { this.content = content; } private String getContent() { return content; } }

}

// Caretaker：编辑历史管理器
class EditorHistory {
private final Deque<TextEditor.Snapshot> undoStack = new ArrayDeque<>();
private final Deque<TextEditor.Snapshot> redoStack = new ArrayDeque<>();

public void save(TextEditor editor) { undoStack.push(editor.save()); redoStack.clear(); // 新操作使重做历史失效 } public void undo(TextEditor editor) { if (!undoStack.isEmpty()) { redoStack.push(editor.save()); // 当前状态存入重做栈 editor.restore(undoStack.pop()); // 恢复到上一个快照 } } public void redo(TextEditor editor) { if (!redoStack.isEmpty()) { undoStack.push(editor.save()); // 当前状态存入撤销栈 editor.restore(redoStack.pop()); // 恢复到下一个快照 } }

}
角色对照：

Originator（发起人）：TextEditor，持有编辑器内容，提供 save 和 restore
Memento（备忘录）：TextEditor.Snapshot，只保存 content 字符串
Caretaker（管理者）：EditorHistory，同时维护撤销栈和重做栈
关键点：EditorHistory 不知道 TextEditor 内部存了什么——Snapshot 里的 content 对它完全隐藏。undo 和 redo 之前都先把当前状态保存到对方栈里，这样可以在撤销和重做之间无损切换。每次新操作（save）清空 redoStack，因为编辑历史已经分叉。

⚠️ 深拷贝陷阱
上面的例子里，content.toString() 恰好是安全的——String 不可变，快照存的字符串永远不会被后续修改影响。但这是个巧合：一旦 Originator 的状态包含可变对象（List、Map、数组、自定义可变类），只做浅拷贝就会埋下 bug——快照和当前状态共享同一个引用，恢复时恢复的是被改过的同一个对象。

// ❌ 错误示范：Memento 只存了 List 的引用
class Document {
private List lines = new ArrayList<>();

public void addLine(String line) { lines.add(line); } public Memento save() { return new Memento(lines); // 存的是引用，不是副本！ } public void restore(Memento m) { this.lines = m.getLines(); } static class Memento { private final List<String> lines; private Memento(List<String> lines) { this.lines = lines; } private List<String> getLines() { return lines; } }

}

Document doc = new Document();
doc.addLine(“第一行”);
Memento snap = doc.save(); // 想快照当前的 [“第一行”]
doc.addLine(“第二行”); // 继续编辑
doc.restore(snap); // 期望恢复成 [“第一行”]
// 实际结果：[“第一行”, “第二行”] —— 快照里的 List 就是当前这个 List，早被改花了
根因是快照和发起人指向同一个可变对象。正确做法是存取两端都做深拷贝——不光 save() 时要拷一份进 Memento，restore() 时也要再拷一份出来，否则恢复后 Originator 又和 Memento 内部的 List 共享了引用(这个快照如果还留在栈里,比如 redo 场景可能被复用,后续修改就会穿透回去,快照就不"快"了)：

public Memento save() {
return new Memento(new ArrayList<>(lines)); // 存:拷一份副本进快照
}

public void restore(Memento m) {
this.lines = new ArrayList<>(m.getLines()); // 取:再拷一份出来,不共享引用
}
只有两端都深拷贝，才能保证 Originator 和 Memento 永远不共享同一个可变对象。状态嵌套更深时（如 Map<String, List>），浅层 new ArrayList<>(…) 还不够——里层元素仍是共享引用，需要逐层深拷贝。此时可以借助原型模式的 clone()，或用序列化再反序列化（Serializable + ObjectOutputStream）做一次性深拷贝。这也呼应了后文「备忘录 vs 原型」里两者互补的关系。

一句话记忆：Memento 存的是"快照"，不是"引用"。只要字段可变，创建备忘录时就必须深拷贝。

总结
本质：在不破坏封装性的前提下捕获对象内部状态，并支持稍后恢复到该状态。

什么时候用：

需要实现撤销/重做（Ctrl+Z、Ctrl+Y）功能
需要在特定时机保存对象快照，如游戏存档、事务保存点
需要回滚到某个历史状态，如工作流回退、审批撤回
需要在对象状态复杂时，避免让外部通过 getter/setter 挨个读写
什么时候不用：

对象状态简单，直接备份字段更清晰
内存敏感的场景——每个快照都是完整状态副本，大对象频繁快照会爆内存
状态可以通过"反向操作"轻松撤销（如加法→减法），用命令模式更省内存
状态变化不需要历史追溯，只关心最新值
内存管理策略：备忘录最大的代价就是内存——每个快照都是一份完整副本。真实项目中常用以下手段控制开销：

限制历史栈深度：Caretaker 设一个最大容量（如只保留最近 50 步），入栈超限时丢弃最老的快照（可用 ArrayDeque + 手动裁剪，或 LinkedHashMap 的 LRU 淘汰）
增量/差量快照：不存完整状态，只存相对上一个快照的变化部分（类似 Git 的 diff），恢复时叠加回放。适合状态大、单次改动小的场景
持久化到磁盘：对可序列化的状态，把较老的快照写到磁盘或数据库，释放堆内存，需要时再读回（游戏存档、事务日志都是这个思路）
简单记忆：状态存进保险箱，箱子交给别人扛；只有自己能打开，历史随时能返场。

相似模式区分
总览
模式 核心意图 典型场景
备忘录 保存对象状态快照用于恢复 撤销/重做、游戏存档、事务回滚
命令 将操作请求封装为对象，可撤销/排队/记录 菜单命令、宏录制、事务日志
原型 通过克隆现有对象创建新实例 对象创建成本高、避免重新初始化
简单记忆：备忘录管"回到过去"，命令管"执行逆操作"，原型管"复制一份"。

备忘录 vs 命令
两者都常用于实现"撤销"功能，但本质不同：

维度 备忘录模式 命令模式
核心意图 保存对象状态快照，用于回滚 将操作请求封装为对象，可执行/撤销
结构差异 Memento 存状态数据，Originator 创建和恢复 Command 存行为（接收者+execute/undo），Invoker 调度
关注点 封装内部状态，外部不可见 解耦请求发送者与接收者
典型场景 编辑器内容、游戏存档、事务回滚 菜单命令、宏、事务日志
逐步区分法：

如果撤销时只需要恢复成原来的样子 → 选备忘录（用状态回滚）
如果撤销时需要执行反向操作 → 选命令（如加法的逆操作是减法）
如果状态数据量极大（如大文本、图像） → 选命令更省内存（只记录操作而非完整状态）
如果操作本身不可逆（如发送邮件、扣款） → 只能用备忘录（保存操作前的完整状态）
简单记忆口诀：备忘录是"时光倒流"（替换状态），命令是"撤销操作"（执行逆操作）。

推荐：状态简单可以计算逆操作时用命令，状态复杂或不可逆时用备忘录。两者也可以结合——命令内部持有备忘录，撤销时用备忘录恢复状态。

备忘录 vs 原型
两者都涉及"复制对象状态"，容易混淆：

维度 备忘录模式 原型模式
核心意图 保存状态以备恢复（时间维度） 复制对象以创建新实例（空间维度）
结构差异 Memento 是独立快照对象，Originator 可读写它 Clone 对象是原型的副本，各自独立演化
关注点 封装——外部不应知道保存了什么 多态——无需知道具体类即可克隆
典型场景 撤销/重做、事务回滚、游戏存档 对象创建成本高、需要大量相似对象
逐步区分法：

如果需要把对象恢复到之前的状态 → 选备忘录
如果需要基于现有对象创建独立的新对象 → 选原型
如果既要保存又要新建 → 两者可以结合：用原型 clone() 生成快照，作为备忘录的内容
简单记忆口诀：备忘录问"我过去是什么样"（时间回溯），原型问"给我一个一样的"（空间复制）。

推荐：在 Java 中实现备忘录时，创建 Memento 经常需要深拷贝 Originator 的状态——此时可以借用原型模式（clone()）辅助实现快照。两者不是互斥而是互补关系。

练习题目
计数器的撤销与重做
题目描述：小明正在设计一个计数器应用，支持加 1（Increment）和减 1（Decrement）操作，以及撤销（Undo）和重做（Redo）操作。请使用备忘录模式帮他实现。

规则：

计数器初始值为 0
每次执行 Increment 或 Decrement 前，需保存当前状态快照到撤销栈，并清空重做栈
Undo 操作：将当前状态保存到重做栈，并从撤销栈恢复上一个状态
Redo 操作：将当前状态保存到撤销栈，并从重做栈恢复下一个状态
保证输入中 Undo 和 Redo 操作都是合法的（撤销栈/重做栈不会为空）
输入描述：输入包含若干行，每行一个字符串，表示操作：Increment、Decrement、Undo、Redo。

输出描述：每行输出一个整数，表示每次操作后计数器的当前值。

输入示例：

Increment
Increment
Decrement
Undo
Redo
Undo
Increment
Undo
输出示例：

1
2
1
2
1
2
3
2
解题思路：本题的核心是理解备忘录模式在撤销/重做中的作用——通过"保存快照+恢复快照"实现状态回溯，而不是通过"执行逆操作"。

角色对应：

Originator（发起人）：Counter，持有 count 字段，能创建和恢复自身的 Memento
Memento（备忘录）：Counter.Memento 内部类，只保存一个 int 值
Caretaker（管理者）：CounterHistory，同时维护撤销栈和重做栈
核心逻辑：

Increment/Decrement 之前先 save，同时清空重做栈——新操作让历史分叉
Undo/Redo 都遵循同一个套路：先把当前状态保存到对方栈，再从当前栈弹出快照并恢复
Memento 内部类的构造器和 getter 都是 private，CounterHistory 只能持有它但打不开
import java.util.*;

public class Main {
public static void main(String[] args) {
Scanner sc = new Scanner(System.in);
Counter counter = new Counter(0);
CounterHistory history = new CounterHistory();

while (sc.hasNext()) { String op = sc.next(); switch (op) { case "Increment": history.save(counter); counter.increment(); System.out.println(counter.getCount()); break; case "Decrement": history.save(counter); counter.decrement(); System.out.println(counter.getCount()); break; case "Undo": history.undo(counter); System.out.println(counter.getCount()); break; case "Redo": history.redo(counter); System.out.println(counter.getCount()); break; } } }

}

// Originator：计数器
class Counter {
private int count;

public Counter(int count) { this.count = count; } public void increment() { count++; } public void decrement() { count--; } public int getCount() { return count; } public Memento save() { return new Memento(count); } public void restore(Memento memento) { this.count = memento.getCount(); } // Memento：备忘录内部类 static class Memento { private final int count; private Memento(int count) { // 私有构造：只有 Counter 能创建 this.count = count; } private int getCount() { // 私有 getter：只有 Counter 能读取 return count; } }

}

// Caretaker：历史管理器
class CounterHistory {
private Deque<Counter.Memento> undoStack = new ArrayDeque<>();
private Deque<Counter.Memento> redoStack = new ArrayDeque<>();

public void save(Counter counter) { undoStack.push(counter.save()); redoStack.clear(); // 新操作使重做历史失效 } public void undo(Counter counter) { redoStack.push(counter.save()); // 当前状态存入重做栈 counter.restore(undoStack.pop()); // 从撤销栈恢复上一个状态 } public void redo(Counter counter) { undoStack.push(counter.save()); // 当前状态存入撤销栈 counter.restore(redoStack.pop()); // 从重做栈恢复下一个状态 }

}
扩展：实际项目中的备忘录模式
javax.swing.undo 撤销框架
JDK 的 javax.swing.undo 包是备忘录模式在 Java 标准库中最典型的应用：UndoableEdit 承担快照角色，UndoManager 充当 Caretaker，管理器不关心每个编辑对象内部存了什么，只负责按栈顺序调用它们的 undo 和 redo 方法。做过 Swing 富文本编辑器的开发者会立刻认出这个套路——所有 JTextArea、JEditorPane 的撤销功能底层都是它。

严格来说，UndoableEdit 是 Command 与 Memento 的混合体：它同时存了 oldValue/newValue（状态快照，Memento 的职责），又封装了 undo()/redo() 的操作行为（Command 的职责，undo 执行逆操作）。这正是前文「备忘录 vs 命令」里推荐过的组合用法——命令内部持有备忘录：undo 时用保存的旧状态恢复现场。所以不必纠结它到底算哪个模式，它本就是两者的落地融合。

UndoManager undoManager = new UndoManager();

class MyEdit extends AbstractUndoableEdit {
private String oldValue, newValue;
private JTextField target;

public MyEdit(JTextField target, String oldValue, String newValue) { this.target = target; this.oldValue = oldValue; this.newValue = newValue; } public void undo() throws CannotUndoException { super.undo(); target.setText(oldValue); // 恢复到 oldValue —— Memento 恢复 } public void redo() throws CannotRedoException { super.redo(); target.setText(newValue); }

}

undoManager.addEdit(new MyEdit(textField, oldValue, newValue));
undoManager.undo(); // 委托给最近一个 Memento
数据库事务保存点
JDBC 的 Savepoint 本质上是备忘录模式在数据库层面的实现——事务执行到某一点时创建快照，出错时可回滚到该点而非整个事务。Connection 是 Originator（状态持有者），Savepoint 是 Memento，应用代码只能拿到 Savepoint 对象但完全无法窥探其内部内容——所有细节由数据库内部管理。银行转账、多步骤订单创建这类需要"部分回滚"的场景，都靠 Savepoint 撑起。

conn.setAutoCommit(false);
// 执行第一批操作…
Savepoint afterOrder = conn.setSavepoint(“after_order”); // 创建快照
// 执行第二批操作…
if (库存不足) {
conn.rollback(afterOrder); // 恢复到保存点
}
conn.commit();
Hibernate 脏检查中的快照
Hibernate 在加载实体时会保存一份原始状态快照，事务提交时比较当前状态和快照，判断哪些字段被修改（脏检查），从而只生成必要的 UPDATE 语句。这个"原始状态快照"借用了备忘录的状态捕获 + 封装机制——快照存在 Hibernate 内部，应用代码完全感知不到它的存在。但要说明的是:标准备忘录的核心意图是把对象恢复回先前状态(方向向后),而 Hibernate 快照的用途是差异比较(方向向前:决定写哪些 UPDATE),并不把实体回滚成旧值。所以它更准确地说是备忘录模式的一个变体应用——共享了"不破坏封装地捕获内部状态"这一子原理,但目的不同,GoF 原书也并未覆盖这个场景。用过 @Entity 的开发者其实每天都在享受这个机制带来的好处。

// Hibernate 内部原理示意
Object[] snapshot = copyOf(entity.getPersistedState()); // 加载时创建快照
// … 业务代码修改 entity …
Object[] current = entity.getPersistedState();
for (int i = 0; i < current.length; i++) {
if (!Objects.equals(current[i], snapshot[i])) {
// 该字段被修改，加入 UPDATE 语句
}
}
游戏存档系统
游戏需要支持存档（save）和读档（load），每个存档记录游戏在某一时刻的完整状态——玩家等级、血量、装备、任务进度等。存档对象（Memento）对存档管理器完全封闭，可以序列化到磁盘长期保存。Steam 云存档、单机游戏的 F5 快速存档、模拟器状态存档，本质都是这套结构。

class Game {
private int level, health, score;

public GameSave save() { return new GameSave(level, health, score); } public void load(GameSave save) { // 外部类 Game 可直接访问内部类 GameSave 的 private 字段——这是 Java 内部类的特权 this.level = save.level; this.health = save.health; this.score = save.score; } // 内部类：存档对象，字段全 private final static class GameSave implements Serializable { private final int level, health, score; private GameSave(int level, int health, int score) { this.level = level; this.health = health; this.score = score; } }

}
表单草稿保存与恢复
Web 表单场景中，用户填写多步表单时可暂存草稿，稍后回来继续。草稿管理器只按用户 ID 存取草稿对象，完全不知道表单里有哪些字段。加了字段、改了字段名，管理器代码一行都不用改——这就是备忘录封装带来的可维护性红利。不管是招聘系统的简历填写、电商的收货地址、还是政务系统的申请表，遇到"稍后继续"都能靠这个套路解决。

class RegistrationForm {
private String username, email, phone;

public FormDraft saveDraft() { return new FormDraft(username, email, phone); } public void restoreDraft(FormDraft draft) { this.username = draft.getUsername(); this.email = draft.getEmail(); this.phone = draft.getPhone(); } static class FormDraft { private final String username, email, phone; private FormDraft(String username, String email, String phone) { this.username = username; this.email = email; this.phone = phone; } private String getUsername() { return username; } private String getEmail() { return email; } private String getPhone() { return phone; } }

}
现在可能还用不到这些，但等到需要撤销、需要存档、需要事务回滚的时候会突然发现：“这不就是备忘录模式吗？”——那时候就真的懂了。

多对象协调快照
前面所有示例都是单个 Originator 的单对象快照。但实际项目里常需要多个对象在同一时刻做协调快照——比如下单场景要同时保存「订单 + 库存 + 支付」三者的状态，形成一个统一的保存点。如果各存各的、恢复时机不一致，就可能回滚到"订单已扣、库存未扣"这种中间不一致态。

做法是把多个 Memento 打包成一个复合备忘录（Composite Memento）：Caretaker 在同一时刻为每个 Originator 调用 save，把结果一起封装；恢复时按相同顺序全部 restore，保证要么一起回到过去，要么都不动。

// 复合备忘录：打包多个对象的快照
class CompositeMemento {
private final Order.Memento orderMemento;
private final Inventory.Memento inventoryMemento;
private final Payment.Memento paymentMemento;

CompositeMemento(Order.Memento o, Inventory.Memento i, Payment.Memento p) { this.orderMemento = o; this.inventoryMemento = i; this.paymentMemento = p; } // 各字段的 getter 省略 ...

}

// Caretaker：协调多个 Originator 的统一保存点
class TransactionCoordinator {
private final Deque savepoints = new ArrayDeque<>();

// 同一时刻为三者一起打快照 public void save(Order order, Inventory inventory, Payment payment) { savepoints.push(new CompositeMemento( order.save(), inventory.save(), payment.save())); } // 恢复时按相同顺序全部 restore，保证一致性 public void rollback(Order order, Inventory inventory, Payment payment) { if (!savepoints.isEmpty()) { CompositeMemento cm = savepoints.pop(); order.restore(cm.getOrderMemento()); inventory.restore(cm.getInventoryMemento()); payment.restore(cm.getPaymentMemento()); } }

}
这其实就是数据库事务保存点在应用层的手写版——Savepoint 之所以能"部分回滚一整批操作"，靠的正是同一时刻的一致性快照。多对象协调快照的难点不在模式本身，而在恢复的原子性：如果 restore 到一半失败，就需要额外的补偿机制（或干脆整体不可变、全部替换）来避免恢复过程本身制造出新的中间态。