## 01、痛点

你有没有见过这样的配置管理后台：用户改了几个参数，然后发现改错了，想回到上一步，结果刷新页面直接回到初始值？或者你想做个撤销按钮，结果发现要把所有字段手动存一遍？

我是老李，一个写了多年 Java 后端的开发者。最近接到一个需求，做一个配置编辑器的撤销重做功能，我以为很简单，结果差点陷入临时变量的海洋。

最开始，配置只有三个字段，最直接的写法是：

```java
public void updateConfig(Config newConfig) {
    // 先保存旧值
    String oldHost = config.getHost();
    int oldPort = config.getPort();
    // 修改
    config.setHost(newConfig.getHost());
    config.setPort(newConfig.getPort());
    // 想撤销？手动恢复
}
```

后来字段多了，每次修改前要深拷贝整个对象，修改后把副本塞进列表，恢复时手动一一赋值：

```java
public void updateConfig(Config newConfig) {
    Config backup = deepCopy(config);
    config.setHost(...);
    config.setPort(...);
    config.setMaxConnections(...);
    config.setTimeout(...);
    // 需要撤销时，再 deepCopy 回来
}
```

再后来需求升级：不仅支持单次撤销，还要支持重做、恢复到指定历史版本。于是有人开始把配置序列化成 JSON 存进 List，恢复时再反序列化。看似聪明，但很快发现：新增一个字段，恢复逻辑漏了一处；快照对象被外部修改，历史状态被污染；内存占用随快照数量线性增长。

代码从几个临时变量，发展成散落在各处的 `deepCopy`、JSON 字符串、手动赋值。一个配置编辑器，硬是写出了“意大利面条”。

这就是最典型的“变化开始失控”。设计模式真正解决的，并不是“代码写得不高级”，而是当撤销、重做、版本回滚这类需求出现时，你如何把状态保存与恢复的职责收拢起来，而不是让备份逻辑像野草一样到处长。

> 锐评：如果配置只有两个字段，撤销就是重新填一下的事，硬套备忘录模式，除了多写几个类，你还得多付内存账单。

## 02、是什么

备忘录模式（Memento Pattern）从一个非常朴素的想法开始：**在不破坏对象封装的前提下，把一个对象的内部状态保存下来，并且之后可以恢复。**

它不是深拷贝，也不是简单的序列化，而是一套关于“状态快照”的职责划分。

三个角色：

- **Originator（发起人）**：业务对象本身。它知道如何创建自己的快照，也知道如何从快照恢复状态。
- **Memento（备忘录）**：状态快照。它保存 Originator 在某个时刻的内部状态，通常设计为不可变对象，对外部隐藏内部字段。
- **Caretaker（负责人）**：管理快照。它只负责保存、取出、组织 Memento，不关心快照里具体是什么。

三者关系可以这样看：

```
+----------------+       creates        +----------------+
|   Originator   | -------------------> |    Memento     |
|  (业务对象)    |                       |  (状态快照)    |
|                | <------------------- |   (不可变)     |
| createMemento()|       restores       |                |
| restore(m)     |                       +----------------+
+----------------+                                ^
        ^                                         |
        | manages                                |
        |                                        |
+----------------+                               |
|   Caretaker    | ------------------------------+
|  (管理者)      |
| 持有快照列表/栈 |
+----------------+
```

注意，Memento 对外通常只暴露一个“空壳”接口，甚至不暴露任何方法。Originator 通过内部类或包内可见的方式访问 Memento 的字段，这样就保证了封装不被破坏。Caretaker 只拿到 Memento 的引用，却无法修改或读取里面的内容——它只知道“这是一个快照”。

从工程视角看，备忘录模式不是代码模板，而是一种“职责如何拆、变化放在哪里”的思考方式。当你在代码中看到需要保存历史状态、恢复状态、回退版本时，就可以想到它。

一个简单的判断映射：

```
需要保存对象历史状态？
├── 只要一步回退 → 单个 Memento
├── 需要 Undo/Redo → 两个栈（undoStack/redoStack）
├── 需要恢复到任意历史版本 → List + 索引
└── 需要持久化 → Memento 序列化
```

## 03、为什么

很多开发者学过备忘录模式，却不会在真实项目中使用。常见误区有三个：

**误区一：把 Memento 当成深拷贝。** 于是每次备份都复制整个对象，恢复时再赋值回来。代码里到处是 `clone()`、`copy()`，看起来像备忘录，实际上根本没把状态保存的职责从业务对象中分离出来。更糟的是，如果对象内部有引用类型，浅拷贝会导致历史快照被意外修改。

**误区二：认为必须把 Memento 做成公共接口让 Caretaker 随意读取。** 结果 Memento 变成了一个普通 DTO，任何人都能改，封装荡然无存。备忘录模式的精髓就是“窄接口”——对外只暴露一个无状态的空接口，只有 Originator 能访问内部数据。

**误区三：所有字段都保存，不考虑内存。** 如果有几十个字段，每次都完整复制，快照一多，内存直接爆炸。备忘录模式确实会增加内存占用，但这并不意味着你可以无脑保存所有状态。往往只需要保存“变化的部分”。

判断一个场景是否值得使用备忘录模式，可以问自己五个问题：

1. 是否真的需要回到历史状态？
2. 状态恢复是否频繁，而且必须精确恢复？
3. 对象的内部状态是否不应该被外部随意访问？
4. 手动备份是否已经导致大量重复代码或容易漏字段？
5. 引入模式后，理解成本是否低于原来的维护成本？

一个简单的判断公式：

```
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果未来变化成本降低得很少，而当前要多写几个类、多维护一条管理链路，那就不值得。

> 锐评：十行代码就能解决的撤销，不要写成一场架构发布会。设计模式不是让你炫耀抽象能力，而是让你在面对变化时少改几行代码。

## 04、架构

备忘录模式在实践中很少单独出现，它通常需要和数据结构配合，才能解决真实问题。

围绕“状态管理”这个核心问题，可以画一张实践地图：

```
需要保存对象历史状态？
├── 只需要一步回退 → 单个 Memento
├── 需要 Undo/Redo → 两个栈（undoStack/redoStack）
├── 需要恢复到任意历史版本 → List + 索引
└── 需要持久化 → Memento 序列化
```

Undo/Redo 的场景，最常见的结构是双栈：

```
undoStack              redoStack
+----------+           +----------+
| 快照 3   |           | 快照 4   |
+----------+           +----------+
| 快照 2   |           | 快照 5   |
+----------+           +----------+
| 快照 1   |           |          |
+----------+           +----------+

undo: 从 undoStack pop 一个，压入 redoStack，恢复
redo: 从 redoStack pop 一个，压入 undoStack，恢复
```

多版本管理则更像一个带游标的列表：

```
versions = [v1, v2, v3, v4, v5]
currentIndex = 3

恢复指定版本：currentIndex = index; restore(versions[index])
```

完整的模式选择思路可以归纳为：

```
需求变化（需要撤销/重做/版本恢复）
↓
变化点识别（状态快照）
↓
职责拆分（Originator 负责状态，Memento 负责快照，Caretaker 负责管理）
↓
模式选择（备忘录模式）
↓
接口稳定（createMemento() / restore()）
↓
实现扩展（增加快照存储方式：内存、磁盘、数据库）
```

也就是说，备忘录模式的核心不是“创建一个 Memento 类”，而是把状态保存与恢复的职责从业务代码中剥离，放到明确的位置。这样后续无论是增加 Undo 还是切换存储方式，都不用改动 Originator。

## 05、实战

这一节我们用配置编辑器做一次完整重构。

**业务场景**

一个后端配置管理页面，用户可以修改多个配置项，包括主机地址、端口、最大连接数、超时时间等。产品要求：每次修改前自动保存当前状态；支持撤销（Undo）、重做（Redo）；支持查看历史版本列表，并恢复到任意一个历史版本。

**第一版代码**

最直观的写法是：在 `ConfigService` 里维护一个 `Config` 对象，修改前手动保存旧值，修改后判断是否需要恢复。

```java
public class ConfigService {
    private Config config = new Config();

    public void updateHost(String newHost) {
        String oldHost = config.getHost();
        config.setHost(newHost);
        // 到处都可能需要 oldHost 来撤销
    }

    public void undoHost() {
        // 这怎么知道 oldHost 是哪个？还得再存
    }
}
```

很快，`ConfigService` 里塞满了各种 `oldXxx` 字段，或者为了撤销，每次修改前都复制整个 `Config` 对象，存到一个 `List<Config>` 里。恢复时再手动遍历字段赋值。新增一个字段，备份和恢复代码都要改两处，漏一处就出 bug。

**模式重构**

我们引入备忘录模式，把 `Config` 作为 Originator，定义一个不可变的 `ConfigMemento` 作为快照，再用一个 `ConfigHistory` 作为 Caretaker 管理 Undo/Redo 和多版本列表。

核心代码：

```java
public class AppConfig {
    private String host;
    private int port;
    private int maxConnections;
    private int timeout;

    // 省略 getter/setter

    public ConfigMemento save() {
        return new ConfigMemento(host, port, maxConnections, timeout);
    }

    public void restore(ConfigMemento memento) {
        this.host = memento.host;
        this.port = memento.port;
        this.maxConnections = memento.maxConnections;
        this.timeout = memento.timeout;
    }

    // 静态内部类，字段私有，只有 AppConfig 能访问
    public static class ConfigMemento {
        private final String host;
        private final int port;
        private final int maxConnections;
        private final int timeout;

        private ConfigMemento(String host, int port, int maxConnections, int timeout) {
            this.host = host;
            this.port = port;
            this.maxConnections = maxConnections;
            this.timeout = timeout;
        }
    }
}
```

Caretaker 管理 Undo/Redo 和版本列表：

```java
public class ConfigHistory {
    private final Deque<AppConfig.ConfigMemento> undoStack = new ArrayDeque<>();
    private final Deque<AppConfig.ConfigMemento> redoStack = new ArrayDeque<>();
    private final List<AppConfig.ConfigMemento> versions = new ArrayList<>();
    private int currentVersion = -1;

    public void backup(AppConfig.ConfigMemento memento) {
        undoStack.push(memento);
        redoStack.clear();
    }

    public AppConfig.ConfigMemento undo() {
        if (undoStack.isEmpty()) throw new IllegalStateException("Nothing to undo");
        AppConfig.ConfigMemento memento = undoStack.pop();
        redoStack.push(memento);
        return memento;
    }

    public AppConfig.ConfigMemento redo() {
        if (redoStack.isEmpty()) throw new IllegalStateException("Nothing to redo");
        AppConfig.ConfigMemento memento = redoStack.pop();
        undoStack.push(memento);
        return memento;
    }

    public void saveVersion(AppConfig.ConfigMemento memento) {
        versions.add(memento);
        currentVersion = versions.size() - 1;
    }

    public AppConfig.ConfigMemento restoreVersion(int index) {
        if (index < 0 || index >= versions.size()) throw new IllegalArgumentException("Invalid version");
        currentVersion = index;
        return versions.get(index);
    }
}
```

使用示例：

```java
AppConfig config = new AppConfig();
ConfigHistory history = new ConfigHistory();

// 初始状态
history.backup(config.save());
config.setHost("db1.example.com");
history.backup(config.save());
config.setHost("db2.example.com");
history.backup(config.save());

// 撤销到 db1
config.restore(history.undo());
// 重做到 db2
config.restore(history.redo());

// 保存历史版本
history.saveVersion(config.save());
// 恢复到第一个版本
config.restore(history.restoreVersion(0));
```

**结构变化**

重构前，`ConfigService` 自己管理备份、恢复、历史列表，导致大量重复代码和潜在的状态污染：

```
ConfigService
| 直接操作临时变量、深拷贝、JSON 序列化
| 到处是 if/else 手动恢复
↓
一团乱麻
```

重构后，职责清晰：

```
AppConfig (Originator)
   |
   +-- save() -> ConfigMemento
   +-- restore(memento)

ConfigMemento (不可变快照)

ConfigHistory (Caretaker)
   |
   +-- undoStack / redoStack
   +-- versions list

调用方 -> AppConfig -> ConfigHistory
```

**收益**

- 状态保存与业务逻辑分离，`AppConfig` 只负责创建和恢复快照，不需要知道快照存在哪里。
- Undo/Redo 和版本管理逻辑内聚在 `ConfigHistory`，修改存储策略不影响 Originator。
- 新增配置字段时，只需修改 `AppConfig` 和 `ConfigMemento` 的构造，管理逻辑不用动。
- 更好的封装性：`ConfigMemento` 字段私有，外部无法篡改历史快照。

**代价**

- 类数量增加，需要理解三个角色之间的关系。
- 每保存一次快照就复制一次状态，内存占用随快照数量线性增长。
- 如果快照保存非常频繁，可能会产生大量冗余数据。

**什么时候不要用**

- 对象只有两三个字段，且撤销需求简单，手动备份更直观。
- 对象非常巨大，而且只需要回退部分字段，应该考虑命令模式或增量快照，而不是完整快照。
- 系统对内存非常敏感，且快照数量可能成千上万，需要谨慎设计存储。

> 锐评：备忘录模式不是深拷贝的升级版，而是把“保存”和“恢复”收拢到明确职责。如果只想着复制对象，那和直接存 JSON 没有本质区别，还多了几个类。

**判断口诀**：

> 备忘录模式：把状态的保存与恢复收拢到 Originator，让 Caretaker 只关心快照的存放，而不是把备份代码撒得到处都是。

## 06、洞见

从会使用备忘录模式，到会判断状态管理需求，需要几个洞见。

**洞见一：设计模式真正关注的是“变化”，不是“类”。** 备忘录模式的出现，是因为状态变化需要被记录、恢复、管理。如果状态永远不变，就不需要快照。

**洞见二：封装是备忘录模式的灵魂。** Memento 对外暴露得越少，历史快照被随意修改的风险就越低。很多人把 Memento 做成公共 DTO，看似方便，实则打破了模式的价值。

**洞见三：Undo/Redo 的本质是栈结构，不是备忘录自己。** 备忘录只负责保存状态快照，而栈结构决定如何推进和回退。两者分离，才能灵活切换为版本列表或持久化存储。

**洞见四：Caretaker 可以演化成版本管理系统，但不要一开始就上数据库。** 先明确快照的生命周期、数量上限、是否需要持久化，再决定存储介质。过早优化存储结构，只会增加复杂性。

**洞见五：很多框架中都有快照思想。** 数据库事务的回滚日志、IDE 的修改历史、浏览器的后退栈，本质上都是备忘录模式的变体。理解了这个思想，你就能在看框架源码时多一层视角。

> 锐评：初级开发者喜欢把撤销写成 if-else，高级开发者开始保存快照，架构师会问：这个快照要不要持久化？内存能不能接受？哪些字段可以不用保存？

## 07、行动

不要一上来就背“三个角色、五个步骤”。建议分三个阶段。

**第一阶段：认识核心角色，写一个最小示例。** 用 Java 写一个 `AppConfig` 类，包含两三个字段，实现 `save()` 和 `restore()`，再写一个 `ConfigHistory` 用 `Deque` 实现 Undo/Redo。跑起来，感受状态如何保存和恢复。

**第二阶段：从自己的项目里找“状态管理”需求。** 比如需要撤销的表单、需要回滚的配置、需要多版本对比的文档。每天找一个这样的场景，问自己：

- 变化点是什么？
- 不使用模式会怎样？当前备份逻辑是不是已经散落各处？
- 使用模式增加了什么复杂度？多几个类？多一层间接？
- 下一次新增状态字段，需要修改几个地方？
- 内存成本是否可接受？

**第三阶段：实施重构。** 挑一个真实场景，按下面七天计划动手。

**七天实践计划**

- **Day 1**：手写一个简单 Memento，保存一个对象的状态快照。
- **Day 2**：实现 Undo，用 `Deque` 管理撤销栈。
- **Day 3**：加入 Redo，使用双栈结构。
- **Day 4**：改成多版本列表，用 `List` 和一个索引管理历史版本。
- **Day 5**：模拟配置多次修改，并恢复到指定历史版本。
- **Day 6**：评估内存占用，观察快照数量增长时对象大小的变化。
- **Day 7**：重新思考：哪些状态其实不用保存？是否可以只保存变化字段？哪些重构其实没有必要？

## 08、小结

> 备忘录模式不是给你一个后悔药，而是让你在不破坏封装的前提下，把后悔的能力设计进去。

真正值得学习的不是三个角色的名字，而是管理状态变化的边界。当你下一次面对撤销、重做、版本回滚时，不再手忙脚乱地复制对象，而是自然地划分 Originator、Memento、Caretaker，并合理地控制快照的生命周期。

如果读完这篇文章，你少写了一个手动深拷贝的临时变量，这篇文章就算没有白写。

## 09、链接与概念说明

- **GoF 是什么**：GoF（Gang of Four）指《设计模式：可复用面向对象软件的基础》一书的四位作者。备忘录模式是该书定义的 23 种设计模式之一，属于行为型模式。
- **创建型 / 结构型 / 行为型分别解决什么问题**：创建型模式解决对象创建时的复杂度和变化；结构型模式解决类或对象的组合关系；行为型模式解决对象之间的职责分配和通信方式。备忘录模式属于行为型，解决状态保存与恢复的职责分配。
- **SOLID 原则与备忘录模式的关系**：单一职责原则（SRP）体现在 Originator 不负责保存历史，Caretaker 不关心状态内容；开闭原则（OCP）体现在新增状态字段时，只需扩展 Memento 和 Originator 的构造，管理逻辑可以保持不变。
- **“开闭原则”为什么经常和设计模式一起出现**：开闭原则要求对扩展开放、对修改关闭。设计模式通常通过抽象和多态来隔离变化，使得新增功能不需要修改已有代码。备忘录模式通过对状态快照的封装，可以让存储策略扩展而不影响 Originator。
- **推荐继续阅读**：《设计模式：可复用面向对象软件的基础》（GoF）、《Head First 设计模式》、Martin Fowler 的《重构：改善既有代码的设计》。这些资料能帮助你建立更完整的模式判断力。

你有没有见过这样的配置管理后台：用户改了几个参数，然后发现改错了，想回到上一步，结果刷新页面直接回到初始值？或者你想做个撤销按钮，结果发现要把所有字段手动存一遍？

《设计模式军体拳第19招》 备忘录模式 Memento——保存对象快照并恢复历史状态

配置管理需要支持撤销、重做和版本恢复。本文通过真实配置编辑器场景，展示如何用备忘录模式保存状态快照、隔离变化，并讨论多版本管理与内存代价。

架构师

人工智能

配置编辑器的撤销重做功能容易因状态保存散乱而失控，本文解析备忘录模式如何通过Originator、Memento、Caretaker三角色收拢快照职责，实现高效Undo/Redo与版本回滚，并分享实战重构案例与适用边界。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第19招》 备忘录模式 Memento——保存对象快照并恢复历史状态-腾讯云开发者社区-腾讯云

《设计模式军体拳第19招》备忘录模式 Memento——保存对象快照并恢复历史状态

《设计模式军体拳第19招》备忘录模式 Memento——保存对象快照并恢复历史状态

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第19招》 备忘录模式 Memento——保存对象快照并恢复历史状态

《设计模式军体拳第19招》 备忘录模式 Memento——保存对象快照并恢复历史状态

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第19招》备忘录模式 Memento——保存对象快照并恢复历史状态

《设计模式军体拳第19招》备忘录模式 Memento——保存对象快照并恢复历史状态