## 01、痛点

我是老李。

先看一段真实代码。

我们系统里有一个营销活动配置对象 CampaignConfig，字段将近 40 个，包括活动名称、时间、渠道、预算、规则列表、奖品列表、风控参数、扩展属性等。早期创建新活动时，业务方说“复制上个月的活动，改个时间和预算就行”。

第一版代码很直接：

```java
CampaignConfig newConfig = new CampaignConfig();
newConfig.setName("2025-06 大促");
newConfig.setStartTime(old.getStartTime());
newConfig.setEndTime(old.getEndTime());
newConfig.setChannel(old.getChannel());
newConfig.setBudget(100000);
// ... 还有 30 多行 set 复制
```

当时觉得没什么，字段就那么多，复制一次也就几十行。

后来活动类型越来越多，CampaignConfig 增加了规则引擎配置、人群包、AB 实验参数等嵌套对象，字段膨胀到 80 多个。复制逻辑散落在三个服务里：活动服务、定时任务、审批回调。每新增一个字段，就要改三四处复制代码，漏改一次就是一个线上事故。

更麻烦的是，CampaignConfig 内部还有 List<RuleConfig>、Map<String, PrizeConfig>，直接 set 引用导致新活动和旧活动共享同一个集合，修改新活动规则时，旧活动也被改了。排查了两个小时，最后发现是浅拷贝问题。

代码失控的典型表现：

```
CampaignService
|
+-- 复制活动：手动 set 40 个字段
+-- 复制活动：又 set 40 个字段（另一个方法）
+-- 修改新活动规则 -> 旧活动规则也被改
```

> 锐评：复制粘贴不是问题，问题是复制粘贴没有统一入口，每次复制都是一场“字段枚举大赛”。字段越多，漏得越狠。

设计模式真正要解决的，不是“代码写得不高级”，而是“变化开始失控”。当复制逻辑从 20 行变成 200 行，并且散落在多个地方时，就需要考虑原型模式了。

## 02、是什么

从工程视角看，原型模式不是教科书上的“通过复制现有对象来创建新对象”那么简单。它本质上是把“对象创建”从“从零初始化”变成“以现有对象为模板复制”。

三个层次理解：

第一层：代码复用。把重复的字段复制逻辑收敛到一个 clone 方法里。

第二层：隔离变化。复制时只需要修改差异部分，而不是关心所有字段。

第三层：管理复杂度。当对象结构复杂、创建成本高时，复制现有对象比 new 再 set 更稳定、更高效。

模式不是代码模板，而是一种“职责如何拆、变化放在哪里”的思考方式。看到什么代码坏味道，可以联想到原型模式：

```
对象创建时需要复制大量字段 → 原型模式
创建对象成本高（查数据库、复杂计算） → 原型模式
需要保留对象当前状态作为模板 → 原型模式
```

GoF 把设计模式分为创建型、结构型、行为型。原型模式属于创建型，但它和工厂模式、建造者模式解决的问题不一样：

- 工厂模式：隐藏创建细节，返回一个可用对象。
- 建造者模式：分步骤构建复杂对象。
- 原型模式：以现有对象为模板，复制出一个新对象。

一个简洁的字符映射：

```
创建对象问题
├── 需要隐藏 new 细节 → 工厂
├── 需要分步骤构建 → 建造者
├── 需要复制现有状态 → 原型
└── 需要全局唯一 → 单例
```

原型模式的核心不是“克隆”，而是“用复制代替初始化”。

## 03、为什么

很多开发者学过原型模式，但在真实项目中不会用。原因有三个误区。

误区一：先记模式，再找地方套。背下来“原型模式是复制对象”，然后满项目找 clone 场景，但发现大部分对象直接 new 就行，于是觉得模式没用。

误区二：看到复制就上原型模式。一个只有三个字段的 DTO，硬要实现 Cloneable，还搞深拷贝，类数量没增加，但代码理解成本上去了。

误区三：抽象层越多越高级。为了原型模式引入 PrototypeManager、PrototypeRegistry、CloneFactory 一堆类，结果生产环境没人维护。

判断原型模式是否值得使用的标准：

1. 对象创建成本是否高？如果只是 new 一个空对象，原型模式没优势。
2. 是否需要大量复制现有状态？如果只需要复制一两个字段，手动 set 更直观。
3. 对象结构是否稳定？如果字段经常变，clone 方法也要经常改，可能不如工厂。
4. 是否需要深拷贝？如果内部引用对象，浅拷贝会带来共享状态问题。
5. 引入后理解成本是否低于原来的复制维护成本？如果团队没人懂 clone 的深浅拷贝陷阱，上了反而更危险。

一个简单的判断公式：

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

如果复制逻辑只出现一次，且字段不超过 10 个，原型模式就是过度设计。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。原型模式不是给简单对象复制用的，是给创建成本高、复制频繁、结构复杂的对象用的。

## 04、架构

把原型模式放回创建型模式的问题地图里，才能建立判断力。

```
变化类型一：对象怎么创建？
├── 创建逻辑简单，直接 new
├── 创建逻辑复杂，但不需要复制 → 工厂
├── 创建逻辑复杂，需要分步骤 → 建造者
├── 需要以现有对象为模板 → 原型
└── 需要全局唯一 → 单例

变化类型二：对象状态如何管理？
├── 需要复制后独立修改 → 深拷贝原型
├── 可以共享不可变部分 → 浅拷贝 + 写时复制
└── 需要缓存原型模板 → 原型注册表
```

```
需求变化
↓
识别变化点：对象创建成本、字段复制维护
↓
职责拆分：将“复制逻辑”收敛到对象自身
↓
模式选择：原型模式（如果复制频繁且对象复杂）
↓
接口稳定：提供 clone() 或拷贝构造器
↓
实现扩展：支持浅拷贝、深拷贝、序列化拷贝
```

原型模式在 Java 中最常见的落地方式有两种：

1. 实现 Cloneable 接口，重写 clone() 方法。
2. 提供拷贝构造器或静态工厂方法，手动复制字段。

Java 的 Object.clone() 是 protected 方法，必须实现 Cloneable 标记接口，而且默认是浅拷贝。这个设计一直被诟病，因为 Cloneable 没有声明 clone 方法，只是一个标记，容易让人误以为实现了接口就能安全克隆。

Spring 框架中也有原型思想：@Scope("prototype") 的 Bean 每次获取都会创建新实例，虽然不是通过 clone 实现，但解决了“复用对象定义，创建新实例”的问题。

## 05、实战

这一章用三个真实场景讲透原型模式。

### 5.1 基础克隆：浅拷贝陷阱与解决

场景：营销活动配置复制。

第一版代码：

```java
public class CampaignConfig {
    private String name;
    private Date startTime;
    private Date endTime;
    private List<RuleConfig> rules;
    private Map<String, PrizeConfig> prizes;
    // 省略 40 个字段 getter/setter
}
```

复制逻辑散落在服务里：

```java
CampaignConfig newConfig = new CampaignConfig();
newConfig.setName(old.getName());
newConfig.setStartTime(old.getStartTime());
newConfig.setEndTime(old.getEndTime());
newConfig.setRules(old.getRules()); // 直接引用
newConfig.setPrizes(old.getPrizes()); // 直接引用
```

问题：newConfig 和 old 共享 rules 和 prizes，修改新活动的规则会污染旧活动。

模式重构：

```java
public class CampaignConfig implements Cloneable {
    // 字段省略

    @Override
    public CampaignConfig clone() {
        try {
            CampaignConfig copy = (CampaignConfig) super.clone();
            // 深拷贝可变引用
            copy.setRules(new ArrayList<>(this.rules));
            copy.setPrizes(new HashMap<>(this.prizes));
            // 如果 RuleConfig 内部还有可变对象，需要递归拷贝
            return copy;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
}
```

调用方：

```java
CampaignConfig newConfig = old.clone();
newConfig.setName("2025-06 大促");
newConfig.setBudget(100000);
```

结构变化：

```
传统写法：
OrderService
|
+-- 手动 set 40 个字段
+-- 手动 set 40 个字段（另一处）
+-- 深浅拷贝全靠自觉

重构后：
OrderService
|
v
CampaignConfig.clone()
|
+-- 统一复制所有字段
+-- 深拷贝可变对象
+-- 调用方只改差异
```

收益：
- 复制逻辑收敛到一个方法。
- 新增字段时只需修改 clone()。
- 避免共享引用问题。
- 调用方代码从 40 行变成 3 行。

代价：
- 必须实现 Cloneable，理解 CloneNotSupportedException。
- 深拷贝需要递归处理嵌套对象，容易遗漏。
- clone() 方法内部如果忘了拷贝某个可变引用，还是会有共享问题。

什么时候不要用：
- 对象只有简单字段（String、int、Date 等不可变或值类型），浅拷贝就够了，但直接 new 可能更清晰。
- 对象字段频繁变化，每次都要改 clone，不如用拷贝构造器。

> 锐评：Object.clone() 的浅拷贝陷阱是谁踩谁知道。如果你不知道 clone 默认只复制引用，就别急着在生产环境上用原型模式。

### 5.2 深拷贝实现：序列化 or 手动递归

当对象嵌套层级很深时，手动递归拷贝会变成噩梦。可以采用序列化实现深拷贝，但需要所有对象可序列化。

```java
public class CampaignConfig implements Serializable {
    // 字段省略
}

public static CampaignConfig deepCopy(CampaignConfig source) {
    try {
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(bos);
        oos.writeObject(source);
        ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray()));
        return (CampaignConfig) ois.readObject();
    } catch (IOException | ClassNotFoundException e) {
        throw new RuntimeException(e);
    }
}
```

优点：代码简单，自动处理所有嵌套对象。
缺点：性能较差，所有对象必须 Serializable，而且 transient 字段不会被复制。对于频繁复制的大对象，序列化可能成为瓶颈。

更推荐的方式：拷贝构造器。

```java
public class CampaignConfig {
    private String name;
    private Date startTime;
    private List<RuleConfig> rules;

    public CampaignConfig(CampaignConfig source) {
        this.name = source.name;
        this.startTime = new Date(source.startTime.getTime());
        this.rules = new ArrayList<>();
        for (RuleConfig rule : source.rules) {
            this.rules.add(new RuleConfig(rule)); // RuleConfig 也提供拷贝构造器
        }
    }
}
```

调用：

```java
CampaignConfig newConfig = new CampaignConfig(old);
```

拷贝构造器比 Cloneable 更直观，没有 checked exception，也更容易控制深拷贝范围。

### 5.3 原型注册表与 Spring 原型作用域

当系统中有多个原型模板时，可以引入原型注册表。

```java
public class PrototypeRegistry {
    private Map<String, CampaignConfig> prototypes = new HashMap<>();

    public void register(String key, CampaignConfig prototype) {
        prototypes.put(key, prototype);
    }

    public CampaignConfig create(String key) {
        CampaignConfig prototype = prototypes.get(key);
        return prototype != null ? prototype.clone() : null;
    }
}
```

使用时，先注册几个活动模板，比如“满减模板”“秒杀模板”，然后通过 key 复制出新的活动配置。

Spring 中的 @Scope("prototype") 虽然不像 clone 那样复制对象状态，但它也体现了“以定义为模板创建新实例”的思想。每次从容器获取 prototype Bean，Spring 会创建一个新的实例，而不是返回单例。这可以帮助理解原型模式在框架层面的应用。

```java
@Component
@Scope("prototype")
public class OrderHandler {
    // 每次注入都是新实例
}
```

但注意：Spring prototype Bean 的创建是通过反射调用构造器，不是通过 clone()，所以无法复制现有对象状态。原型模式在框架中更多是思想借鉴。

## 06、洞见

写完这几个案例，你会发现原型模式真正的能力不是“复制对象”，而是“识别对象创建成本”。

洞见一：设计模式关注的是“变化”，不是“类”。原型模式的核心变化点是“对象创建方式从初始化变为复制”。

洞见二：好的抽象来自重复出现的变化，而不是提前想象。如果复制逻辑只出现一次，不要抽象；当复制逻辑散落在三个服务、字段 80 个时，原型模式才自然长出来。

洞见三：模式最重要的价值是降低修改半径。使用原型模式后，新增字段只需要改 clone() 或拷贝构造器，而不是改所有复制代码。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。对于简单对象，直接 new 比任何模式都清晰。

洞见五：很多 Java 框架就是设计模式的大型实践。Cloneable 接口虽然设计得不好，但它是原型模式在 JDK 中的直接体现；Spring 的 prototype scope 借鉴了原型思想；Java 序列化可以作为一种深拷贝实现。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。原型模式也一样，不是所有复制都值得用 clone。

## 07、行动

不要试图背下所有创建型模式，先掌握原型模式的判断和使用。

第一阶段：认识原型模式的核心

掌握：
- Cloneable 和 clone() 的浅拷贝陷阱。
- 深拷贝的三种方式：手动递归、拷贝构造器、序列化。
- 原型注册表的使用场景。

第二阶段：在自己的项目里找坏味道

找这三类代码：
1. 大量手动 set 复制的代码。
2. 对象创建需要查数据库、复杂计算，但复制现有对象可以大幅提升性能。
3. 修改复制对象时，原对象被意外修改的问题。

第三阶段：尝试重构

每次重构回答五个问题：
1. 复制逻辑是否散落在多个地方？
2. 对象创建成本是否真的高？
3. 使用原型模式后，新增字段需要修改几个地方？
4. 深拷贝是否处理了所有可变引用？
5. 新人是否更容易理解拷贝构造器比 Cloneable 更直观？

七天实践计划：

Day 1：找一个字段超过 20 个且复制逻辑重复出现的对象。
Day 2：用拷贝构造器替换手动复制，统一复制入口。
Day 3：检查对象内部是否有可变引用，如果修改副本影响了原对象，说明需要深拷贝。
Day 4：尝试实现 Cloneable，对比拷贝构造器的优缺点。
Day 5：如果复制逻辑集中在某个工厂类，思考是否引入原型注册表。
Day 6：阅读 Spring prototype scope 的文档，理解框架中的原型思想。
Day 7：重新评估：哪些复制其实不需要抽象？哪些深拷贝是过度设计？

## 08、小结

> 设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。

原型模式解决的是“对象创建方式”的变化：当创建成本高、需要以现有对象为模板复制时，把复制逻辑收敛到一个方法里，降低维护成本。但原型模式不是免费午餐，它有浅拷贝陷阱、Cloneable 设计缺陷、序列化性能开销等代价。

真正值得学习的不是“原型模式”这四个字，而是看到变化、识别变化、隔离变化的能力。如果读完这篇文章，你少写了一个 200 行的手动 set 复制，这篇文章就算没有白写。

## 09、链接与概念说明

- GoF：指《设计模式：可复用面向对象软件的基础》一书，由 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 合著，提出了 23 种设计模式。
- 创建型模式：解决对象创建过程中的变化，包括工厂方法、抽象工厂、建造者、原型、单例。
- 原型模式：通过复制现有对象来创建新对象，减少重复初始化，隔离对象创建与使用。
- 浅拷贝：复制对象时，只复制基本类型和引用地址，引用指向同一个对象。修改副本的引用对象会影响原对象。
- 深拷贝：复制对象时，递归复制所有引用对象，副本与原对象完全独立。
- Cloneable 接口：Java 标记接口，实现它才能调用 Object.clone()，但只有浅拷贝，且设计受争议。推荐阅读《Effective Java》第 13 条“谨慎地覆盖 clone”。
- Java 序列化：通过 ObjectOutputStream/ObjectInputStream 可以实现深拷贝，但要求所有对象实现 Serializable，且性能较差。
- Spring Bean 作用域：@Scope("prototype") 表示每次获取 Bean 都创建新实例，借鉴了原型模式的思想，但通过反射创建，不是通过 clone。
- 推荐资料：《Effective Java》（Joshua Bloch）、《设计模式》（GoF）、《Head First 设计模式》。

我们系统里有一个营销活动配置对象 CampaignConfig，字段将近 40 个，包括活动名称、时间、渠道、预算、规则列表、奖品列表、风控参数、扩展属性等。早期创建新活动时，业务方说“复制上个月的活动，改个时间和预算就行”。

原型模式：复制现有对象，为什么比 new 更靠谱？一次讲透深浅拷贝与真实场景

从营销活动配置复制的真实项目出发，讲清原型模式的适用场景、Object.clone 浅拷贝陷阱、深拷贝实现、原型注册表，以及什么时候不该用原型模式。

架构师

编程语言

后端

原型模式解决对象复制失控问题：将散落的字段复制逻辑收敛到clone方法，统一创建入口，避免共享引用污染。适用于字段多、创建成本高、需复制现有状态的场景。注意深拷贝陷阱，可通过拷贝构造器实现。评估收益：降低复制维护成本，但避免过度设计。

代码解释

数据库

容器

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

原型模式：复制现有对象，为什么比 new 更靠谱？一次讲透深浅拷贝与真实场景-腾讯云开发者社区-腾讯云

原型模式：复制现有对象，为什么比 new 更靠谱？一次讲透深浅拷贝与真实场景

原型模式：复制现有对象，为什么比 new 更靠谱？一次讲透深浅拷贝与真实场景

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐