其实，

几乎每个业务程序都有“撤销”需求。但大多数实现却与 Memento 模式毫无关系。它们往往只是把一个 JSON 快照存到数据库，接下来在使用者点撤销时把旧数据覆盖回来。按理说，这样的做法虽然能跑，但它并不是 Memento。

为什么大多数实现不是真正的 Memento？

Memento 的主要不是“备份”。而是封装状态的访问边界——让 Originator 自己管自己的状态，外部只负责存取一个黑盒，不能偷看里面装了什么。缺失这一点会导致：

• 字段级恢复变得困难；
• 新增字段导致旧快照出现空值覆盖；
• 无法满足业务对安全/权限的细粒度控制。

再看真实踩坑场景。电商后台订单编辑程序

三年前，我接手一个电商后台订单编辑程序。运营改完订单信息后需要撤销回上一步。

• 痛点 1：快照粒度过粗 – 只存整个 OrderDTO，无法按字段恢复。
• 痛点 2：字段增删导致空值覆盖 – 新增字段导致旧快照反序列化后为空值，从而覆盖别人的数据。
• 痛点 3：维护成本高 – 因为业务演进，每次改 DTO 就要重构快照逻辑。

当时的实现：

// 每次编辑前把整个 OrderDTO 序列化成 JSON 存入 order_undo_log 表
// 撤销时反序列化并覆盖当前数据

Memento 的真正结构与约束

Memento 模式包含三个角色：

• Originator: 拥有需要保存的状态，负责创建和恢复 Memento。
• Memento: 封装状态，对除 Originator 外所有对象隐藏内部细节。
• Caretaker: 保存 Memento，不得操作或检查其内容。老实说，

public interface OrderMemento { /* 空接口 */ }
public class OrderEditor {
private String address;private BigDecimal price;private String remark;public OrderMemento save {
return new Snapshot;}
public void restore {
Snapshot s = m;this.address = s.address;this.price = s.price;this.remark = s.remark;}
private static class Snapshot implements OrderMemento {
final String address;final BigDecimal price;final String remark;Snapshot {
this.address = a;this.price = p;this.remark = r;}
}
}
public class UndoManager {
private final Deque stack = new ArrayDeque<>;public void push { stack.push;}
public OrderMemento pop { return stack.pop;}
}

This structure ensures that ,acting as Caretaker,has no visibility into what’s inside an . Even if 's internal state changes。UndoManager remains unchanged.

与数据库快照、Event Sourcing 的区别

• 数据库快照：侧重持久层备份，关注“数据丢失后如何恢复”。 通常粒度为整张表或整个库，不涉及业务对象封装边界。
• Memento：面向领域层，用于“当前会话内操作回退”。主要约束是 Caretaker 必须保持黑盒性。
• Event Sourcing：仅存事件，不存状态。撤销等价于追加逆向事件，可 replay、审计，但复杂度更高。适用于需要完整历史追溯和分支回放的场景；若仅需单步/多步撤销，则 Memento 足够。

三个工程化陷阱与解决思路

. Memento 内存爆炸 & 性能瓶颈

• 痛点：- 每次变更都保存完整快照，高频操作快速占满内存/磁盘。
• 方法：- 增量 Memento：只记录变更字段，但仍通过 Originator 输出统一黑盒；- 快照 + 操作日志：每 N 步保存一次完整快照，其余记录 Command；在撤销时先找到最近快照再 replay 逆向操作；老实说，- 惰性复制/不可变结构：共享未变更的数据。只复制变化部分，实现物理上可控复制成本。

. 深拷贝 vs 引用泄露

• 痛点：- 存引用导致后续修改污染历史记录；深拷贝则对大对象性能消耗巨大。
• 权衡策略：- 值对象直接引用；- 集合和自定义对象必须深拷贝，可以使用 clone、CopyOnWriteArrayList 或 Jackson 序列化/反序列化等方法。虽笨但稳妥，

. 多 Originator 的交叉恢复

• 痛点：- 一个 Caretaker 管理多个 Originator，单纯按堆栈弹出无法确定要恢复哪一方状态。怎么说呢，
#Command模式补位 **Note这方面。** 为了保持代码可读性，这里省略了一些冗余标签。java public interface EditCommand { void execute;void undo，} public class ChangePriceCommand implements EditCommand { private final OrderEditor editor;private OrderMemento backup;怎么说呢，private final BigDecimal newPrice;其实，public ChangePriceCommand { this.editor = editor;this.newPrice = newPrice;} @Override public void execute { backup = editor.save;// 执行前保存 editor.setPrice;} @Override public void undo { editor.restore;} }

Mementos 管理“怎么存状态”，Commands 管理“什么时候存、存谁”。两者协同才能搭建工业级撤销程序。

什么时候该用 Mementos？

• 内部结构可能变化 → 用 Mementos，以封装隔离变化风险。
• Caretaker 不应知晓内部细节 → 用，因为黑盒天然满足安全/权限要求。
• 多级撤销且状态对象庞大 → 考虑增量或 Command+Snapshot 组合方案，以控制内存与性能开销。说起来，
• 仅简单单字段修改且结构极稳定 → 可直接缓存旧值。无需硬套模式，避免过度设计。