23个设计模式一文搞懂

本笔记涵盖 23 种经典设计模式，按创建型、结构型、行为型三大类整理。每个模式配有生活类比、核心思想、结构图解、实现要点、真实应用案例、适用场景、优缺点分析及常见面试题。

目录

• 设计原则（SOLID）
• 创建型模式（5种）
• 结构型模式（7种）
• 行为型模式（11种）
• 模式之间的关系
• 模式速查表

一、设计原则（SOLID）

S — 单一职责原则（Single Responsibility Principle）

一个类只应该承担一种职责，只做一件事。如果一个类承担了多种职责，那么它发生变化的原因就会有多个，违反了高内聚低耦合的原则。

应用案例：在电商系统中，OrderService 只负责订单的创建、查询、取消等订单相关操作，不应该同时负责发送邮件通知或库存管理。邮件通知交给 NotificationService，库存管理交给 InventoryService。

O — 开闭原则（Open/Closed Principle）

软件实体对扩展开放、对修改关闭。当需要增加新功能时，应该通过增加新代码来实现，而不是修改已有的代码。这是设计模式中最核心的原则。

应用案例：支付系统中，新增"微信支付"时只需要新增 WechatPayStrategy 类，不需要修改已有的 PayService 代码。通过策略模式实现开闭原则。

L — 里氏替换原则（Liskov Substitution Principle）

所有引用父类的地方必须能够透明地替换为子类的对象，且程序行为不变。子类不能改变父类已有方法的语义。

应用案例：Bird 类有 fly() 方法，但 Penguin（企鹅）继承 Bird 后不能飞，重写 fly() 抛出异常——这违反了里氏替换原则。正确做法是设计 FlyingBird 和 Penguin 两个独立的类。

I — 接口隔离原则（Interface Segregation Principle）

客户端不应该被迫依赖它不使用的接口。接口应该小而专，而不是大而全。一个类对另一个类的依赖应该建立在最小的接口上。

应用案例：不应该设计一个庞大的 IEmployee 接口包含 work()、eat()、sleep() 方法，因为机器人员工不需要 eat() 和 sleep()。应该拆分为 IWorkable、IEatable、ISleepable 三个小接口。

D — 依赖倒置原则（Dependency Inversion Principle）

高层模块不应该依赖低层模块，二者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。简单说就是"面向接口编程，而不是面向实现编程"。

应用案例：OrderService 依赖 IRepository 接口而不是具体的 MySQLRepository。当需要切换到 MongoDBRepository 时，只需要更改注入的实现类，OrderService 完全不用改。

二、创建型模式（5种）— 关注"怎么创建对象"

创建型模式将对象的创建和使用分离，降低了代码的耦合度。

01 单例模式 Singleton

一句话理解

整个程序运行期间，某个类只能有一个实例对象。

生活类比

全国只能有一个皇帝。不管谁去请旨，面对的都是同一个人。如果有人想再立一个皇帝，那是谋反。

核心思想

构造方法私有化 + 静态变量 + 全局访问点 = 单例。

实现方式详解

方式一：双重检查锁（最常用）

• 第一次检查：如果已经创建了，直接返回，不需要进锁（性能优化）
• 第二次检查：防止多个线程同时通过了第一次检查后重复创建
• 必须加 volatile 关键字：instance = new Singleton() 不是原子操作，JVM 可能重排序为先赋值引用再初始化对象，volatile 可防止此问题

方式二：枚举方式（最简洁，推荐）

• 天然防止反射攻击（反射无法创建枚举实例）
• 天然线程安全（JVM 保证）
• 代码最简洁，是 Effective Java 推荐的方式

真实应用案例

适用场景

优缺点

常见面试题

• 双重检查锁为什么要加 volatile？ instance = new Singleton() 不是原子操作，JVM 可能重排序。加 volatile 可防止此问题。
• 反射能破坏单例吗？ 可以，通过 Constructor.setAccessible(true) 可以调用私有构造方法。但枚举方式天然防御反射。
• 单例在分布式系统中有什么问题？ 单例是 JVM 级别的，不同 JVM 有不同实例。分布式系统需要使用分布式锁或 Redis 等方案保证全局唯一。

02 工厂模式 Factory

一句话理解

不直接 new 对象，而是通过工厂方法来创建对象。

生活类比

你去餐厅不会自己进厨房做菜，而是告诉服务员"来一份宫保鸡丁"。厨师（工厂）根据你的需求做出对应的菜（对象）。

三种工厂模式对比

简单工厂 → 工厂方法 → 抽象工厂
(一个工厂 (每个产品 (每个产品族
创所有产品) 有自己的工厂) 有自己的工厂)

一、简单工厂 (Simple Factory)

• 一个工厂类，根据参数（通常是 switch-case）创建不同的产品
• 优点：逻辑集中，使用简单
• 缺点：每新增一种产品就要修改工厂代码，违反开闭原则
• 也被称为"静态工厂方法"

二、工厂方法 (Factory Method)

• 每种产品有自己的工厂，新增产品只需新增工厂类
• 优点：符合开闭原则，新增产品不改已有代码
• 缺点：类的数量增多

三、抽象工厂 (Abstract Factory)

• 一个工厂生产一整套相关产品（产品族）
• 例如：精灵族的城堡+国王+军队，兽人族的城堡+国王+军队
• 优点：保证产品族风格统一
• 缺点：新增产品类型需要修改所有工厂

真实应用案例

三种工厂怎么选？

优缺点

03 建造者模式 Builder

一句话理解

把复杂对象的"组装过程"和"最终产品"分离开。

生活类比

你去肯德基点套餐：先选汉堡，再选饮料，最后选薯条。服务员按你的要求一步步组装，最后给你一个完整的套餐。你不需要知道汉堡怎么做、饮料怎么调——你只管选，服务员（Builder）负责组装。

核心角色

核心特点

• 链式调用：每个构建方法返回 this，支持 builder.buildType().buildRegion().build() 这样的流畅写法
• 分步构建：将复杂对象的创建分解为多个简单的步骤
• 产品复制：build() 方法中复制结果返回新对象，防止外部修改 Builder 内部状态

真实应用案例

Builder vs 工厂模式

适用场景

优缺点

04 原型模式 Prototype

一句话理解

通过"复制"已有对象来创建新对象，而不是从零 new。

生活类比

你写了一份 Word 文档，觉得不错，Ctrl+C、Ctrl+V 复制了一份。这就是原型模式——从已有的"原型"复制出新对象。

核心思想

实现 Cloneable 接口 → 重写 clone() 方法 → 决定用浅拷贝还是深拷贝。

浅拷贝 vs 深拷贝

浅拷贝：
Level A → Monster ← Level B
↑
两个 Level 指向同一个 Monster！
改 A 的 Monster，B 也会变

深拷贝：
Level A → Monster A
Level B → Monster B （完全独立）

深拷贝的实现方式

• 递归 clone：容易遗漏嵌套的引用类型，不推荐
• 序列化/反序列化：一次性解决所有层级的拷贝，推荐
• JSON 转换：通过 JSON 序列化再反序列化实现深拷贝

真实应用案例

适用场景

优缺点

常见面试题

• 浅拷贝和深拷贝的区别？ 浅拷贝只复制对象本身和基本类型字段，引用类型字段仍指向原对象；深拷贝把引用类型也复制一份，完全独立。
• 为什么推荐序列化方式做深拷贝？ 递归 clone 容易遗漏嵌套的引用类型，序列化/反序列化一次性解决所有层级的拷贝。
• 原型模式和拷贝构造函数的区别？ 原型模式通过 clone() 方法实现，拷贝构造函数通过构造方法实现。拷贝构造函数更灵活，可以处理 final 字段。

三、结构型模式（7种）— 关注"怎么组合类和对象"

结构型模式关注如何将类和对象组合成更大的结构，以实现新功能或简化设计。

05 适配器模式 Adapter

一句话理解

把一个类的接口转换成另一个类需要的接口——就像电源适配器。

生活类比

你从美国带回来一个插头（美标），在中国用不了。怎么办？买个转换头（适配器），插上就能用了。转换头没有改变插头本身，也没有改变墙上的插座，只是在中间做了"翻译"。

核心结构

目标接口（客户端期望的） ← 适配器 ← 被适配者（已有的、不兼容的）

两种适配器对比

真实应用案例

适用场景

优缺点

06 桥接模式 Bridge

一句话理解

把"抽象"和"实现"分开，让它们可以独立变化。

生活类比

遥控器（抽象）和电视（实现）是两个独立的东西。一个遥控器可以控制不同品牌的电视，一个电视也可以被不同遥控器控制。它们通过"信号"这座桥连接。

遥控器（抽象）──── 桥 ──── 电视（实现）
│ │
电视遥控器 海信电视
万能遥控器 小米电视

核心价值

如果不用桥接模式，要为每种存储方式写一个 Persistence 类：DbPersistence、FilePersistence……类爆炸。桥接后：N×M 变成 N+M。

核心结构

抽象层（Persistence） ──── 桥接 ──── 实现层（PersistenceImplementor）
│ │
高级操作 底层存储
saveData() DataBase
updateData() FileSystem

真实应用案例

适用场景

优缺点

常见面试题

• 桥接模式和适配器模式的区别？ 桥接模式是设计时就把抽象和实现分开；适配器模式是事后解决已有类的接口不兼容问题。

07 组合模式 Composite

一句话理解

把"单个对象"和"容器对象"统一处理——像文件和文件夹一样。

生活类比

你操作文件时，删一个文件和删一个文件夹，操作是一样的（右键→删除）。文件夹里可以有文件，也可以有其他文件夹——这就是树形结构。

核心结构

LetterComposite（抽象类）
├── children: List<LetterComposite> ← 持有子节点
├── add() ← 添加子节点
└── print() ← 统一操作（递归）
├── Letter（叶子节点，没有子节点）
└── Sentence（容器节点，包含 Letter）

关键设计

• 抽象组件：定义叶子和容器的公共接口，包含 add()、print() 等方法
• 叶子节点：实现自己的操作，没有子节点
• 容器节点：持有子节点列表，print() 方法递归调用所有子节点的 print()
• 钩子方法：printThisBefore() 和 printThisAfter() 提供扩展点

真实应用案例

适用场景

优缺点

08 装饰器模式 Decorator

一句话理解

不修改原有类，动态地给对象"穿上新功能"——像给手机贴膜、加壳。

生活类比

你买了一杯咖啡（基础对象），可以加糖、加奶、加冰——每加一种就是一个装饰器。加完之后还是咖啡，但功能更强了。

咖啡 → 加糖咖啡 → 加糖加奶咖啡 → 加糖加奶加冰咖啡
↑ ↑ ↑
基础 装饰器1 装饰器2

核心结构

Component（统一接口）
├── ConcreteComponent（被装饰者）
└── Decorator（装饰器基类，持有 Component 引用）
├── ConcreteDecoratorA（加攻击）
└── ConcreteDecoratorB（加防御）

关键设计

• 统一接口：被装饰者和装饰器实现同一个接口
• 装饰器基类：持有被装饰者的引用，默认行为是转发调用
• 具体装饰器：继承装饰器基类，重写方法增强功能
• 自由组合：多个装饰器可以嵌套使用

真实应用案例

装饰器 vs 继承

适用场景

优缺点

09 外观模式 Facade

一句话理解

为复杂的子系统提供一个简单的"一键操作"入口。

生活类比

按一下电脑的开机键，CPU 启动、内存检测、硬盘加载、显示器点亮——你不需要一个一个手动操作，开机键就是"外观"。

核心结构

客户端 → Facade（外观类）→ 子系统A
→ 子系统B
→ 子系统C

客户端只需要调用 Facade，不需要知道子系统的细节。

真实应用案例

适用场景

优缺点

常见面试题

• 外观模式和代理模式的区别？ 外观模式是简化复杂系统的调用；代理模式是控制对对象的访问（权限、缓存、延迟加载等）。
• 什么时候不用外观模式？ 子系统本身就不复杂，或者客户端需要直接操作子系统的细节时。

10 代理模式 Proxy

一句话理解

给对象找一个"替身"，通过替身来控制对原对象的访问。

生活类比

明星不会直接接通告，而是通过经纪人（代理）。经纪人会帮你过滤、审核、安排——你和明星之间多了一层控制。

三种代理对比

三种代理详解

静态代理：手动写一个代理类，实现与目标对象相同的接口。优点是简单直接；缺点是每个接口都要写一个代理类，很啰嗦。

JDK 动态代理（推荐）：基于接口，运行时生成代理类。所有方法调用都会走到 invoke() 方法，可以在这里统一做权限校验、日志记录等。一个 Proxy 处理所有方法。

CGLIB 代理：基于继承，运行时生成子类。不需要接口，通过 Enhancer 创建目标类的子类并重写方法。Spring AOP 默认对有接口的类用 JDK 动态代理，对没有接口的类用 CGLIB。

真实应用案例

适用场景

优缺点

11 享元模式 Flyweight

一句话理解

把相同的部分共享复用，减少内存占用——像 String 常量池。

生活类比

游戏中有 1000 个哥布林，但它们的模型、贴图、动画都是一样的，只有位置不同。如果每个哥布林都加载一套模型，内存就爆了。享元模式的做法：1000 个哥布林共享同一个模型数据（内部状态），只有位置不同（外部状态）。

核心概念

内存对比

不用享元：
100 个治疗药水 = 100 个 Potion 对象 → 占用 100 份内存

用享元：
100 个治疗药水 = 1 个 HealingPotion 对象（共享）+ 100 个引用 → 只占 1 份内存

真实应用案例

与单例的区别

• 单例：一个类只有一个实例（如全局配置）
• 享元：一个类可以有多个实例，但相同的内部状态共享同一个对象（如 String 常量池中有多个不同的字符串对象）

适用场景

优缺点

常见面试题

• 享元模式和单例模式的区别？ 单例是一个类只有一个实例；享元是一个类可以有多个实例，但相同的内部状态共享同一个对象。
• String s = "abc" 和 String s = new String("abc") 的区别？ 前者使用常量池（享元），后者每次都创建新对象。

四、行为型模式（11种）— 关注"对象之间怎么通信"

行为型模式关注对象之间的职责分配和通信方式，定义对象间的交互规则。

12 责任链模式 Chain of Responsibility

一句话理解

请求沿着一条链传递，每个节点决定"处理"还是"传递给下一个"。

生活类比

请假流程：实习生 → 组长 → 经理 → 总监 → CEO。你的请假请求沿着这条链传递，每个人只有权限处理一定天数的请假，超过了就交给上级。

请假 1 天 → 组长批准 ✓（结束）
请假 3 天 → 组长转经理 → 经理批准 ✓（结束）
请假 7 天 → 组长转经理 → 经理转总监 → 总监批准 ✓（结束）

核心结构

RequestHandler（处理者基类）
│
├── next（指向下一个处理者）
└── handleRequest()（处理或传递）
│
OrcSoldier → OrcOfficer → OrcCommander

关键设计

• 抽象处理者：持有下一个处理者的引用（链表结构），提供默认的传递逻辑
• 具体处理者：判断请求类型，能处理就处理，不能处理就调用 super.handleRequest() 传递
• 组装责任链：通过构造函数嵌套创建链 new A(new B(new C(null)))

真实应用案例

适用场景

优缺点

13 命令模式 Command

一句话理解

把"操作"封装成对象——可以保存、撤销、排队执行。

生活类比

餐厅点单：你告诉服务员"来一份宫保鸡丁"，服务员把你的需求写在菜单上（命令对象）。厨师拿到菜单才开始做。菜单可以排队、可以取消、可以记录今天做了什么菜。

核心结构

Invoker（触发者：按钮/遥控器）
│
▼
Command（命令对象：execute() + undo()）
│
▼
Receiver（实际执行者：编辑器/电视）

关键设计

• 命令接口：定义 execute() 方法，可选定义 undo() 方法
• 具体命令：封装 Receiver 和具体操作，持有 Receiver 的引用
• 触发者（Invoker）：持有 Command 引用，调用 command.execute()
• 撤销功能：命令对象中保存被删除的内容，undo() 时恢复

真实应用案例

适用场景

优缺点

14 迭代器模式 Iterator

一句话理解

提供一种统一的方式来遍历集合，不需要知道集合内部怎么存储。

生活类比

你用遥控器换台，只需要按"上一个"、“下一个”，不需要知道电视内部是用数组还是链表存储频道的。

核心结构

Collection（集合）
└── iterator() → 返回 Iterator

Iterator（迭代器）
├── hasNext() → 还有下一个吗？
├── next() → 获取下一个
└── remove() → 删除当前元素

自定义分页迭代器

笔记中实现了一个分页迭代器，支持：

• next() / previous()：翻页
• curr()：获取当前页
• goFirst() / goLast()：跳到首页/末页
• goPage(int pi)：跳到指定页
• pages()：计算总页数
• setPageSize(int size)：设置每页大小

真实应用案例

适用场景

优缺点

15 中介者模式 Mediator

一句话理解

用一个"中介"来协调多个对象之间的交互，避免它们直接互相引用。

生活类比

房产中介：买房的人和卖房的人不直接联系，都通过中介沟通。这样双方不需要知道对方的细节，中介负责协调。

没有中介：
买家 ←→ 卖家 （直接耦合）

有中介：
买家 ←→ 中介 ←→ 卖家 （通过中介解耦）

核心结构

ComponentA ──→ Mediator ←── ComponentB
│
ComponentC ────────┘

组件之间不直接通信，都通过 Mediator 转发。

关键设计

• 中介者接口：定义 triggerEvent() 方法，组件通过事件名通知中介者
• 组件基类：持有 Mediator 引用，变化时通知中介者
• 具体中介者：实现事件分发逻辑，协调组件间的交互

真实应用案例

适用场景

优缺点

16 观察者模式 Observer

一句话理解

一个对象状态变了，自动通知所有关注它的对象——像微信公众号推送。

生活类比

你关注了"人民日报"公众号。每次它发新文章，你都会收到推送通知。你不需要每天去看，公众号会主动告诉你。

公众号（Subject） 粉丝（Observer）
│ │
├── 发布文章 ──→ 自动推送给所有粉丝
│
├── 粉丝A
├── 粉丝B
└── 粉丝C

核心结构

Subject（被观察者）
├── observers: List<Observer>
├── addObserver()
├── removeObserver()
└── notifyAll() ← 状态变化时通知所有观察者

Observer（观察者）
└── update() ← 接收通知，更新自己

关键设计

• Subject：维护观察者列表，提供添加/移除方法，状态变化时遍历通知
• Observer：定义 update() 接口，接收通知并更新自己
• 松耦合：Subject 不知道 Observer 具体是谁，只知道它实现了 Observer 接口
• 游戏案例：角色使用技能时，根据阵营过滤观察者（敌方扣血，友方不受影响）

真实应用案例

适用场景

优缺点

17 状态模式 State

一句话理解

对象在不同状态下有不同的行为——状态变了，行为也跟着变。

生活类比

游戏角色有多种状态：站立、行走、攻击、受伤、死亡。在"站立"状态下可以"行走"；在"攻击"状态下会自动回到"站立"；"死亡"状态下什么也不能做。

站立 ──→ 攻击 ──→ 站立
│ │
↓ ↓
行走 受伤 ──→ 死亡

核心结构

Context（上下文，持有当前 State）
│
▼
State（状态基类）
├── StandState（站立状态）
├── AttackState（攻击状态）
├── HurtState（受伤状态）
└── DeadState（死亡状态）

每个 State 知道自己该做什么，以及何时切换到下一个状态。

关键设计

• 状态基类：定义 onEnter()（进入状态时执行）和 execute()（执行状态行为）
• 上下文：持有当前 State 引用，changeState() 切换状态并触发 onEnter()
• 状态转换：由具体状态类决定（如攻击状态执行后自动切换到站立状态）
• 消除 if-else：不同状态的行为分散到各个状态类中，而不是用大量 if-else 判断

状态转换图

┌─────────────┐
│ StandState │
└──────┬──────┘
│ 攻击
┌──────▼──────┐
│ AttackState │
└──────┬──────┘
│ 被打
┌──────▼──────┐
│ HurtState │ ──→ DeadState（血量为 0 时）
└──────┬──────┘
│ 恢复
┌──────▼──────┐
│ StandState │
└─────────────┘

真实应用案例

适用场景

优缺点

与策略模式的区别

• 状态模式：状态转换由状态对象自身决定（如攻击后自动回到站立）
• 策略模式：策略选择由客户端决定（如客户端选择用攻击策略还是防御策略）

18 策略模式 Strategy

一句话理解

定义一组可以互换的算法，让客户端在运行时选择用哪个。

生活类比

出行方式：去公司可以开车、坐公交、骑自行车。每种方式都是一个"策略"，你可以根据天气、心情随时换。

出行策略接口
├── 开车策略（快但堵车）
├── 公交策略（慢但便宜）
└── 骑车策略（自由但累）

核心结构

Context（上下文，持有策略引用）
│
▼
Strategy（策略接口）
├── ConcreteStrategyA
├── ConcreteStrategyB
└── ConcreteStrategyC

运行时可以随时切换策略。

策略模式 vs if-else

真实应用案例

适用场景

优缺点

19 模板方法 Template Method

一句话理解

在父类中定义"算法骨架"，子类填充具体步骤。

生活类比

泡茶和泡咖啡的流程是一样的：

步骤一样，但"冲泡"和"加配料"不同（茶用茶叶，咖啡用咖啡粉）。父类定义流程骨架，子类填充差异部分。

泡饮模板（父类）：
烧水() ← 通用
冲泡() ← 抽象，子类实现
倒进杯子() ← 通用
加配料() ← 抽象，子类实现

泡茶（子类）：冲泡=放茶叶，加配料=加柠檬
泡咖啡（子类）：冲泡=放咖啡粉，加配料=加牛奶

核心结构

public abstract class AbstractClass {
// 模板方法：定义算法骨架（用 final 防止子类修改）
public final void templateMethod() {
step1(); // 固定步骤
step2(); // 可变步骤（抽象）
step3(); // 可变步骤（抽象）
hook(); // 钩子方法（可选覆盖）
}

private void step1() { /* 通用实现 */ }
protected abstract void step2(); // 子类必须实现
protected abstract void step3(); // 子类必须实现
protected void hook() { } // 钩子，子类可选覆盖
}

关键设计

• 模板方法：用 final 修饰，防止子类修改算法骨架
• 抽象方法：子类必须实现的步骤
• 钩子方法（Hook）：有默认实现，子类可选覆盖，提供扩展点
• 旅行案例：performTrip() 定义了 goTransport() → day1/2/3() → backTransport() 的流程，通用步骤在父类实现，具体行程由子类决定

真实应用案例

经典应用

优缺点

20 访问者模式 Visitor

一句话理解

在不修改元素类的前提下，为它们添加新操作。

生活类比

体检：医生（访问者）拿着体检表去各个科室（元素）检查。每个科室接受检查，但科室本身不用改——改的是医生的检查方式。

体检报告（Visitor）去访问：
内科（Element）→ 接受体检
外科（Element）→ 接受体检
眼科（Element）→ 接受体检

核心结构

Visitor（访问者） → 定义对每种元素的操作
Visitable（可访问元素）→ 定义 accept(Visitor)

双重分派：
element.accept(visitor) ← 第一次分派：选择元素类型
└── visitor.visit(this) ← 第二次分派：选择访问者类型

关键设计

• 双重分派：element.accept(visitor) 调用 visitor.visit(this)，根据 element 和 visitor 的实际类型决定调用哪个 visit() 方法
• 可访问元素：定义 accept(IVisitor visitor) 方法
• 访问者接口：为每种元素类型定义一个 visit() 方法
• 具体访问者：实现具体的访问逻辑（如生成报告）

真实应用案例

适用场景

优缺点

21 解释器模式 Interpreter

一句话理解

为一种语言定义文法，并建立解释器来解析和执行语句。

生活类比

计算器输入 12 + 34，计算器（解释器）解析这个表达式，理解"12"是数字、"+"是运算符、"34"是数字，然后计算出结果 46。

核心结构

Expression（表达式）
├── TerminalExpression （终结符：具体的数字/变量）
└── NonTerminalExpression （非终结符：组合表达式，如加法）

Context（上下文）：存储待解析的字符串和解析结果

罗马数字解析器示例

笔记中实现了一个罗马数字解析器，从高位到低位依次解析：

• 千位表达式：M = 1000
• 百位表达式：C=100, CD=400, D=500, CM=900
• 十位表达式：X=10, XL=40, L=50, XC=90
• 个位表达式：I=1, IV=4, V=5, IX=9

解析 “MCMXCIV” → 1000 + 900 + 90 + 4 = 1994

抽象语法树（AST）

+
/ \\
* C
/ \\
A B

解释器遍历这棵树，计算 (A * B) + C

真实应用案例

适用场景

优缺点

22 备忘录模式 Memento

一句话理解

保存对象的内部状态，以便日后恢复——就是"存档/读档"。

生活类比

玩游戏时的存档功能：打 Boss 前先存个档，打输了就读档重来。存档保存了游戏的完整状态（角色位置、血量、装备等）。

存档（Memento）：保存棋盘当前状态
读档（Restore）：恢复到之前的状态

核心角色

关键设计

• 保存状态：Originator 的 save() 方法创建 Memento，深拷贝防止外部修改
• 恢复状态：Originator 的 restore() 方法从 Memento 读取状态
• 历史管理：Caretaker 用 Stack 保存多个 Memento，支持多次撤销
• 悔棋案例：每次落子前先存档（push），悔棋时读档（pop）

真实应用案例

适用场景

优缺点

常见面试题

• 备忘录模式和序列化有什么区别？ 序列化是把对象转成字节流用于持久化存储；备忘录模式是内存中保存状态快照用于恢复，关注点是"保存/恢复"这个行为模式。
• 备忘录模式和命令模式的区别？ 命令模式的 undo() 方法需要调用备忘录来保存和恢复状态，两者经常配合使用。

五、模式之间的关系

六、模式速查表