1. 为什么需要原型模式：构造函数不够用的时候
先说一个我自己踩过的场景。早几年做一个图形编辑器，里面要支持一种操作：用户选中一个矩形，点“复制”，然后拖到另一个位置。最开始写的时候，我没想太多，直接就是：
if (type == "RECT") { auto rect = new Rect(*currentRect); rect->setX(newX); rect->setY(newY); scene->add(rect); } else if (type == "ELLIPSE") { auto ellipse = new Ellipse(*currentEllipse); ... }每加一种图形，我就要往这个 if-else 链里添一个分支。到后面加了圆角矩形、曲线、文字框、图片框之后，这个函数已经膨胀得没法看了。更难受的是，如果创建对象之前要做一些公共处理——比如检查命名冲突、给新对象生成 ID、把对象挂到图层树上——这些逻辑散落在每个分支里，稍微改一处忘记同步，线上就会出现两个对象 ID 重复的诡异 bug。
原型模式就是把“复制已有的对象实例”这件事从具体类中抽离出来。它的核心思想一句话就能说明白：不通过构造函数来创建对象，而是通过克隆一个现有的对象来创建新对象。C++ 里没有“虚构造函数”这种语法机制，而原型模式恰好弥补了这个缺口：你不需要知道对象的具体类型，照样能“按当前对象的样子”造出新的同类对象。
假设你有几十种图形类型，但代码里只握着它们的基类指针，你是没法 new 出一个具体派生类对象的。prototype 模式的做法是，给每个对象加一个clone()方法，让它自己负责复制自己。调用者拿到任何子类对象，只要调clone()，就能得到一个完完整整的副本，不需要碰任何 switch-case。
这还只是讲清楚它最浅层的价值。真正让原型模式发挥威力的场景是这三类：
- 对象构造代价大，构造函数里做了很多 IO 或耗时计算，直接复制比重新 new + 重新初始化便宜太多。最典型的例子是游戏里的关卡配置、渲染管线状态对象、带缓存的数据聚合器。
- 运行时才能确定具体类型，比如配置文件的 type 字段、插件系统加载的动态类、用户拖拽产生的任意图形对象。
- 对象本身是“稀有原型”，系统里只有一两份实例，业务需要从这仅有的一份中不断复制衍生出大量个体。例如神经网络训练中的超参组对象、文本编辑器里的段落样式对象。
我在实际项目里最深的感觉是，原型模式解决了“对象创建”这件事上的一个哲学级痛点：构造函数是无状态的，你每次 new 都是按模板从零开始；但业务场景里很多时候你需要的不是“空白的初始对象”，而是“当前某个对象的一模一样的快照”。人工一点点把字段搬过去，不仅费劲，还容易搬漏。原型模式让你从“逐字段复制”升级为“整个对象直接复印”，方法论上完全不一样。
还有一个隐藏的收益：原型模式天然支持“对象克隆时不破坏其私有状态”。如果 A 类和 B 类的某些字段是 private 的，外部代码永远无法构造一份和它们一致的副本——除非你把它们全暴露出来。而给类加上clone()之后，类的内部自己掌握复制细节，外部只调用接口，访问控制边界完整保留。这对于做模块划分、SDK 封装来说尤其重要。
2. 最小可用的原型模式：Clone接口与虚析构
动手写代码之前先说明一点：C++ 实现原型模式，跟 Java、Python 的体验完全不同。Java 有 Object.clone() 打底，Python 有 copy 模块撑着，而 C++ 里一切都要你自己定义清楚：返回什么类型、拷贝怎么展开、内存由谁释放，任何一个环节偷懒都会埋雷。所以我下面的示例全部按“可直接放进工程”的标准来写，不是说能编译就完事。
先定义一个最干净的抽象基类：
class Shape { public: virtual ~Shape() = default; virtual Shape* clone() const = 0; virtual void draw() const = 0; virtual std::string type() const = 0; };这里有两个细节必须重点讲。
第一个细节，也是 C++ 原型模式最容易翻车的地方：基类析构函数必须是 virtual。很多初学者会漏掉这行。如果基类析构不是虚的，你通过Shape*删除一个派生类对象，行为是未定义——实际上大多数编译器只会调用基类析构，派生类里申请的资源全部泄漏。原型模式里，调用者清一色拿着基类指针操作clone()返回的对象，释放时更是基类指针，所以virtual ~Shape()不是“建议加上”，而是“没有它代码就是错的”。
第二个细节是clone()返回值。我写的是Shape*，这是为了演示方便。真实工程里我更推荐std::unique_ptr<Shape>作为返回类型，阻塞裸指针带来的所有权混乱，这个问题放到后面第 5 节专门展开。现在先用裸指针，把模式本身的逻辑讲透。
接着实现两个具体形状：
class Circle : public Shape { public: Circle(double radius, double cx, double cy) : radius_(radius), cx_(cx), cy_(cy) {} Shape* clone() const override { return new Circle(*this); // 用拷贝构造完成克隆 } void draw() const override { std::cout << "Circle(r=" << radius_ << ", center=(" << cx_ << "," << cy_ << "))\n"; } std::string type() const override { return "Circle"; } private: double radius_; double cx_; double cy_; }; class Rectangle : public Shape { public: Rectangle(double w, double h) : width_(w), height_(h) {} Shape* clone() const override { return new Rectangle(*this); } void draw() const override { std::cout << "Rectangle(w=" << width_ << ", h=" << height_ << ")\n"; } std::string type() const override { return "Rectangle"; } private: double width_; double height_; };关键点在于return new Circle(*this)这一句。*this是当前对象，new Circle(*this)拿当前对象作为参数调用 Circle 的拷贝构造函数，生成一个逐成员复制的新对象。就这么一条语句，就把“按现有对象创建新对象”这件事办完了。
这时候你可能会问：如果我不写clone()，直接用new Circle(*originalCircle)不是也能复制吗？确实能。但问题就出在“必须知道具体类型”上。假设你有个std::vector<std::unique_ptr<Shape>> shapes，遍历时拿到的是Shape*，你根本不知道背后是 Circle 还是 Rectangle。没有clone()，你只能用 type() 判断，然后强转类型，再调用构造函数。这不就退回到文章开头那个 if-else 地狱了吗？
现在有了clone()，客户代码长这样：
void duplicateShape(const Shape& shape, std::vector<std::unique_ptr<Shape>>& shapes) { Shape* copy = shape.clone(); shapes.emplace_back(copy); // 拿到的对象类型自动正确 }这段代码对 Circle、Rectangle、以后新增的任何 Shape 子类都成立。新增图形时，你只需要在新类里实现clone()，调用方一行都不用改。这就叫对扩展开放、对修改封闭，是原型模式在架构层面的核心价值。
还要提一个面试常考的概念：协变返回类型。C++ 允许派生类覆盖父类虚函数时，返回类型是父类返回类型的派生类型。比如我可以这样设计：
class Circle : public Shape { public: Circle* clone() const override { // 返回 Circle* 而非 Shape* return new Circle(*this); } };这种写法的好处是，当调用者明确知道它操作的是 Circle 时，可以直接拿到Circle*，调用 Circle 特有的方法，不需要强转。协变返回类型不是原型模式的必需项，但属于一种锦上添花的 C++ 特性，写库的时候如果希望给使用者更多便利，可以考虑。
我还想强调一点容易被忽略的“版本契约”问题。Shape 基类的clone()注释里最好写明：“所有派生类必须确保 clone 返回的对象类型与自身类型完全一致，且状态与原对象相等。”为什么强调这个？因为如果某个派生类偷懒，这么写：
Shape* clone() const override { return new Shape(*this); // 错误：对象被切成基类 }这就是典型的对象切片，你拿到了一个“看起来像基类、其实是剥掉派生部分”的残缺对象。这种 bug 在编译期不会报错，运行期行为诡异，排查起来相当费劲。所以原型模式看起来简单，真正落地时，每一层都要认真对待。
3. 深浅拷贝的分野：C++ 原型模式最容易翻车的地方
网上讲原型模式的资料一抓一大把，但大多数教程只拿两个 int 字段举例，clone()里一句return new Circle(*this)就草草收场。一旦你把这个模式搬进真实工程，很快就会发现：真正决定代码质量的是拷贝的“深浅”。这里不夸张地说，原型模式的 bug 至少有三分之一出在拷贝实现错误上。
先归纳一下三个概念的区别：
| 拷贝方式 | 行为 | 复制结果 | 典型用途 |
|---|---|---|---|
| 浅拷贝 | 逐成员复制，指针成员复制地址 | 新旧对象共享堆内存 | 共享大型缓存、只读配置 |
| 深拷贝 | 指针成员也复制指向的内容 | 新旧对象完全独立 | 绝大多数业务场景 |
| 写时复制 | 先共享，写操作时再复制 | 内存轻量、行为独立 | 性能敏感型系统 |
默认的拷贝构造函数执行的是浅拷贝。如果你的类里有一个裸指针成员：
class Circle : public Shape { public: Circle(double radius) : radius_(radius) { pixels_ = new PixelBuffer(1024); } // 默认拷贝构造：直接复制 pixels_ 指针，两个对象指向同一块内存 // 编译器生成：pixels_(other.pixels_) ~Circle() override { delete pixels_; // 两个对象销毁时，同一内存被释放两次 } private: double radius_; PixelBuffer* pixels_; // 堆上缓存 };这种情况下，一个简单的Shape* copy = obj.clone()就会制造出两个指向同一块 PixelBuffer 的 Circle 对象。某天你通过copy修改了缓存，原始对象的数据也被篡改；对象析构时 double free，直接崩溃。这就是浅拷贝 + 原型模式 = 灾难现场。
正确做法是显式提供深拷贝的拷贝构造函数：
class Circle : public Shape { public: Circle(double radius) : radius_(radius) { pixels_ = new PixelBuffer(1024); } Circle(const Circle& other) : Shape(other), radius_(other.radius_) { // 重新分配一块内存，然后逐个字节复制内容 pixels_ = new PixelBuffer(*other.pixels_); } Circle& operator=(const Circle& other) { if (this == &other) return *this; radius_ = other.radius_; delete pixels_; pixels_ = new PixelBuffer(*other.pixels_); return *this; } Shape* clone() const override { return new Circle(*this); // 这里调用的就是上面的深拷贝构造 } ~Circle() override { delete pixels_; } private: double radius_; PixelBuffer* pixels_; };这里有三个必须同步修改的位置：
- 拷贝构造函数：实现真正的深拷贝。
- 拷贝赋值运算符：先释放自己的资源，再复制对方的资源，注意自赋值检查。
clone()本身：确认它走的是你写好的深拷贝路径。
这三处只要改了第一处忘了另外两处，就会出现“clone() 出来的是深拷贝，但赋值的是浅拷贝”“某个成员走深拷贝、另一个成员又走浅拷贝”这类一半正确一半错误的状态。我在 code review 里见到过太多次这种问题了，所以强烈建议：类里面只要有非 POD 的成员，就把拷贝控制三件套（析构函数、拷贝构造、拷贝赋值）全部显式写出来，用 Rule of Three 约束自己，别依赖编译器默认生成的行为。
如果你的类同时是继承体系的成员，还要记得显式调用基类拷贝构造函数。比如：
class FilledCircle : public Circle { public: FilledCircle(const FilledCircle& other) : Circle(other), fill_color_(other.fill_color_) {} // 忘记调用 Circle(other) 的话，基类部分会用默认构造，字段丢失 private: Color fill_color_; };实际开发里还有一种常见情况：某些成员本身就是智能指针。这里要区分语义。std::shared_ptr拷贝是“共享所有权”，两个对象的智能指针指向同一个堆对象，引用计数加一。如果你希望深拷贝，就要特意make_shared复制内容；如果你希望多个对象共享一份大文件数据，那 shared_ptr 的共享语义反而是你想要的。
一个取巧但高效的折中方案是写时复制（Copy-on-Write）。实现不复杂：类里持有shared_ptr<Impl>，克隆时直接共享 Impl，只有等某个对象要修改内部数据时，才做一次真正的拷贝。文本编辑器的文档缓冲、图形引擎的顶点数据，都大量使用这种手法。原型模式的clone()在毫秒级时间里返回一个共享内存的新对象，而实际内容复制被推迟到真正需要的时候，性能上非常可观。不过 CoW 也有自己的坑：每个修改入口都要检查引用计数是否为 1，忘记检查就会出现“改了这一个，所有共享者全变了”的诡异行为。个人建议，除非性能优化真的需要，业务代码优先用朴素的深拷贝，别为了省那点时间引入心智负担。
4. 类型无关的工厂：原型管理器与注册表
如果你觉得原型模式的作用就是“复制对象”，那还是把它看小了。原型模式真正的高级玩法，是利用“原型对象本身作为工厂”这一特性，实现一个不依赖 if-else 的对象创建注册表。这才是配置驱动、插件化架构的基石。
标题里提到“原型设计模式”，很多人在搜索时会把它和“工厂模式”搞混。区别在哪里？工厂模式中，一个工厂类负责创建多种对象，通常还是需要知道具体类型；而原型模式中，对象自己充当自己的工厂，调用方完全可以用一套通用代码接管所有类型的创建。两者并非互斥，但原型模式在“运行时未知类型”这一点上有天然的压倒性优势。
实现原型管理器，第一件事是定义注册表。基于std::unordered_map或std::map，键是对象类型标识，值是原型对象：
class PrototypeRegistry { public: void registerPrototype(const std::string& key, std::unique_ptr<Shape> prototype) { prototypes_[key] = std::move(prototype); } std::unique_ptr<Shape> createClone(const std::string& key) const { auto it = prototypes_.find(key); if (it == prototypes_.end()) { throw std::runtime_error("unknown prototype: " + key); } return std::unique_ptr<Shape>(it->second->clone()); } private: std::map<std::string, std::unique_ptr<Shape>> prototypes_; };使用方式如下：
PrototypeRegistry registry; registry.registerPrototype("circle", std::make_unique<Circle>(5.0, 0.0, 0.0)); registry.registerPrototype("rect", std::make_unique<Rectangle>(100.0, 50.0)); std::unique_ptr<Shape> s1 = registry.createClone("circle"); // 得到一个圆 std::unique_ptr<Shape> s2 = registry.createClone("circle"); // 再得到一个圆有没有注意到，调用方从头到尾没有写过一次new Circle。以后你要新增一百种图形，代码不需要做任何改动，只需要注册即可。注册表模式的本质，是把“哪个类型对应哪个创建逻辑”这张映射表从源码编译期转移到了运行期，从而得到了一个非常宝贵的能力：运行期动态扩展。
最典型的应用就是插件系统。核心模块只定义 Shape 接口和注册表，第三方插件拿到一个空注册表，把自己实现的类注册进来。主程序通过配置文件里的字符串去查表、克隆，根本不知道插件类头的路径。这就是原型模式与依赖解耦的最好示范。
还有一个数据驱动对象创建的常见套路，结合序列化可以做得非常漂亮：
std::unique_ptr<Shape> createShapeFromConfig(const nlohmann::json& config) { std::string type = config["type"]; auto shape = registry.createClone(type); // 这里再根据 config 中的具体字段对 shape 做初始化 return shape; }一套通用的“配置对象类型名 -> 创建对象”逻辑就完成了。虽然细究起来原型模式只负责“克隆出对应类型”，初始化字段是独立计算，但两者配合使用，比手写一百行 if-else 要干净得多。
我实际做过的一个需求是 UI 编辑器中的控件拖拽复制。程序里维护一个控件库列表，点击某个控件时界面显示它的缩略图；用户把它拖到画布上，系统就调用它的clone()生成一个带完整样式的真实控件。这套流程如果不用原型模式，就得写一个switch (control_type)的分发器，每种控件都要手动把字体、颜色、边距、阴影、事件绑定全部复制一遍，累且容易出错。有了注册表，新增控件类型时只需 implement clone，拖拽复制的功能自动生效，整个编辑器加新控件的成本从“改一堆代码”降到了“只写一个新类”。
有一点需要提前设计好：浅层注册表保存的是“原型对象”，但它本身处于什么状态会影响克隆结果。如果你注册的是一个“陈旧的原型”，那克隆出来的对象也是陈旧状态。更常见的设计是，注册表里保存“默认原型”，业务运行中需要复制时，用当前活跃的实例作为克隆来源。所以原型管理器里的原型和运行时业务对象，建议在生命周期上区分开：注册表的原型是模板，运行时的对象是实例，模板不参与业务状态变更。
5. 内存安全：裸指针、智能指针与拷贝语义的取舍
原型模式在 Java 里基本不用操心内存，clone()返回一个Object引用，垃圾回收器兜底。但 C++ 里不行，clone()返回裸指针的话，内存所有权模糊，要么漏 delete，要么 double delete。这是 C++ 原型模式和别的语言最不一样、也最容易出事的地方。
三种返回类型的选择，我直接给出一个对比表：
| 返回类型 | 所有权语义 | 内存安全 | 性能开销 | 我的评价 |
|---|---|---|---|---|
T*裸指针 | 不明确，靠约定 | 低，容易泄漏 | 零 | 教学演示可以，工程不推荐 |
std::unique_ptr<T> | 独占所有权，明确转移 | 高，自动释放 | 零 | 默认首选 |
std::shared_ptr<T> | 共享所有权 | 高，可能产生循环引用 | 引用计数有开销 | 需要共享生命周期时用 |
先说为什么std::unique_ptr<Shape>是首选。它表达的意思非常清楚：clone()创建了一个新的、独立的对象，这个对象的所有权完完全全交给了调用者。调用者拿到之后放入容器、传给其它函数、还是释放掉，都是它的自由。没有共享歧义，没有悬垂引用空间，资源在离开作用域时自动回收。性能上和裸指针一模一样，没有引用计数开销。
写代码时这样定义接口：
class Shape { public: virtual ~Shape() = default; virtual std::unique_ptr<Shape> clone() const = 0; virtual void draw() const = 0; virtual std::string type() const = 0; }; class Circle : public Shape { public: std::unique_ptr<Shape> clone() const override { return std::make_unique<Circle>(*this); } // ... };这里有个细节。std::make_unique<Circle>(*this)直接调用拷贝构造函数，正确又安全。如果 Circle 的拷贝构造实现的是深拷贝，克隆出来的对象自然拥有独立资源。只改clone()签名，整个调用链就安全了一大截：
void useShape(const Shape& source) { auto copy = source.clone(); // std::unique_ptr<Shape> copy->draw(); // 用完自动释放 }再讲异常安全。假设你写的是裸指针版本：
Shape* clone() const override { PixelBuffer* buffer = new PixelBuffer(1024); // 第一次分配 // 这里如果抛异常，buffer 泄漏 auto* shape = new Circle(buffer); // 第二次分配，如果失败 buffer 也泄漏 return shape; }只要new失败一次，中间资源就漏了。改用 unique_ptr 后：
std::unique_ptr<Shape> clone() const override { auto buffer = std::make_unique<PixelBuffer>(1024); auto shape = std::make_unique<Circle>(*this, *buffer); // 任何一步抛异常，之前分配的资源都会被自动清理 return shape; }代码稍微多一点，但安全性从“碰运气”提升到了“随你怎么折腾都不泄漏”。做底层库的朋友应该深有体会，类似这种多步资源分配的地方，裸指针版本写一遍，脑补一遍异常路径都要抖三抖，智能指针版本是真的省心。
那什么时候用std::shared_ptr<Shape>？当多个系统需要同时持有同一个克隆对象并协作修改它，比如一个全局任务队列把自己的副本分享给多个消费者，同时又不想随随便便复制一大块数据。这种情况下 shared_ptr 让所有权天然共享，引用计数自动管理生命周期。代价是每次拷贝会增加一次原子计数操作，这个开销在高频场景下能感受到，但在多数业务代码里微乎其微。
再补充一种更少见但实用的情况：你的对象实现了原型模式，同时也希望支持从外部给出来的另一个对象进行克隆。这时候可以用“外部源 + 转发构造”的方式，在 clone 内部再套一层工厂函数。不过这种技巧非常看具体架构，不是每种类型都适用，这里不展开。
内存安全这块还有一个容易忽略的地方——原型注册表本身持有的是 unique_ptr，但拷贝语义和析构是不是对的？一定要检查注册表插入原型时使用的构造方式。比如registerPrototype("circle", std::make_unique<Circle>(5.0, 0.0, 0.0))，它创建的 Circle 对象被注册表独占。之后createClone返回的是std::unique_ptr<Shape>，注册表里的原型纹丝不动。等到整个 registry 析构时，所有原型对象自动释放。这套生命周期非常干净，不需要额外写析构逻辑。
6. 应用场景实录：从图形编辑器到游戏开发
前面章节更多在讲“怎么实现原型模式”，但不少读者可能更关心“它到底值不值得用”。我拿自己参与过或观察过的项目类型，把原型模式的真实价值摊开来说。
6.1 图形编辑器与文档系统：复制粘贴的基石
这类系统大概是原型模式最直观的受益者。用户选中任意图形、文本、图片框，执行复制粘贴，本质上就是一次“状态克隆”。如果只用构造函数，你必须知道所有选中对象的精确类型，然后逐个类型处理。用原型模式，一个纯虚的clone()就可以覆盖所有对象，新增一种对象也无需改动复制粘贴的核心流程。
我印象很深的一次重构是在一个白板工具里。最开始复制一组元素用的是遍历字段硬拷贝，代码写了一百多行，而且经常漏拷贝“阴影偏移”“旋转角度”这类冷门字段。后来把每个元素类的clone()作为基础接口，复制粘贴逻辑变成：
std::vector<std::unique_ptr<Element>> copies; for (const auto& el : selected) { copies.push_back(el->clone()); }从一百多行缩减成三行，而且复制结果和原对象永远保证一致。这种重构收益是非常直观的，看到代码清爽了，整个人都舒服。
6.2 游戏开发：关卡、敌人与技能效果的批量生成
游戏开发中，同一类敌人的不同变体早就用原型模式用得滚瓜烂熟。策划配置文件里写“DarkElf_Archer_Level3”，程序从注册表里找到对应的原型对象，克隆一份，再改几个数值参数，就直接生成了一个实例。数量再大，也就一行clone()。所以很多游戏引擎的“对象模板”系统，底层就是原型注册表。这在 Unity 里对应 Prefab，在自研引擎里就是原型模式加序列化。
技能系统也是同样的逻辑。一个火球术技能在运行中积累了一些状态（比如伤害加成、弹道偏移角度、元素Buff列表），玩家释放技能时不是从零构造一个新技能，而是克隆当前技能实例，再叠加本次释放的特有参数。这样做的好处是保证每一个新技能都继承了全部基础配置，不会有漏配的数值。
6.3 配置驱动的系统：插件与初始化管线
前面第 4 节已经讲了配置驱动。我再补充一个具体形态：假设你的系统要从 JSON 配置读取几十种类型的对象，如果没有原型模式，通常要写一个巨大的反序列化工厂。有了原型注册表后，反序列化函数只需要：
JsonObject createFromConfig(const std::string& type, const nlohmann::json& cfg) { auto obj = registry.createClone(type); obj->applyConfig(cfg); return obj; }这里对类型是开放的。新增类型，只要实现clone()和applyConfig()，系统其他部分完全不用改。这在插件化架构、脚本化扩展中几乎是标配做法。
6.4 原型模式 vs 其他创建型模式的取舍
写到这里，很自然地想给你一个选型建议，用来回答“为什么用了原型模式而不是工厂模式或直接构造”：
| 对比维度 | 原型模式 | 工厂模式 | 直接构造 |
|---|---|---|---|
| 是否知道具体类型 | 不需要 | 通常需要 | 必须知道 |
| 是否复制现有状态 | 是 | 否，总是新造 | 否 |
| 代码侵入性 | 需要实现 clone | 需要工厂类 | 最低 |
| 运行期扩展 | 容易（注册表） | 需要加分支 | 无 |
| 典型场景 | 复制现有对象、配置驱动创建 | 多类型统一创建 | 简单固定类型 |
如果只是创建一个新对象，状态统一初始，直接用构造就行，不需要引入模式。如果多种类型需要统一创建入口，但类型在编译期已知，工厂模式就够。一旦出现“运行时才知道类型”或“需要复制现有对象完整状态”的需求，原型模式就是最合理的答案。
7. 面试与实战中必须掌握的追问点
围绕“C++ 原型模式”这个高频面试话题，我梳理了几个最常见、也最能测出真实水平的追问。每道题的思考方向我都标注出来了。
7.1 原型模式和拷贝构造有什么区别
这是第一个一定会被问到的问题。刚才第 3 节其实已经暗示了答案：C++ 的拷贝构造函数确实已经能做逐成员复制，但它是静态绑定——你调用拷贝构造时必须知道具体类型。原型模式的核心价值不在于“复制”本身，而在于“基于一个未知具体类型的对象，动态地创建同类型副本”。拷贝构造是语言机制，原型模式是设计模式，后者把前者包装成了多态能力。
7.2 clone() 返回类型应该怎么设计
这个问题考验的是对 C++ 所有权模型的理解。标准答案脉络：教学代码用裸指针可以，但工程代码强烈建议std::unique_ptr<T>，因为所有权语义明确、异常安全；如果多个对象需要共享克隆产物，可以用std::shared_ptr<T>；同时可以利用协变返回类型，让派生类返回自身类型，提升调用方便利性。能把 unique_ptr 和 shared_ptr 的取舍讲清楚，基本能拿高分。
7.3 深拷贝还是浅拷贝？怎么保证安全
凡涉及指针成员，必须显式写深拷贝；涉及 smart pointer 时，根据共享/独占语义选择 shared_ptr 或 unique_ptr；如果追求性能，可以考虑写时复制。要能现场说出三件套的同步修改原则：拷贝构造、赋值运算符、clone() 三处都要一致。这部分就是 C++ 原型模式真正拉开差距的地方。
7.4 为什么 C++ 没有虚构造函数，原型模式如何弥补
这个问题问的是语言机制和设计模式的关系。C++ 的 new 表达式需要知道具体类型，虚构造函数是不存在的语法。原型模式通过让每个对象自己 clone 自己，实现了“用基类指针创建派生类对象”的效果。可以说原型模式就是 C++ 语境里虚构造函数的替代品。
7.5 原型模式适合替换什么样的 if-else 链
这里考察的是设计嗅觉。如果分支条件是“类型”，且分支体是“创建对象”，那这套 if-else 就非常适合替换成原型注册表；如果分支条件是真实业务逻辑，比如根据评分决定走哪条促销链路，那一味用原型模式反而增加复杂度。核心原则：模式解决的是对象创建的多态分发，别拿它生搬硬套所有分支场景。
7.6 实际工程中还应该注意哪些边界
我把自己踩过的坑列成了一个清单，你可以直接收藏：
- 原型对象注册后要防止外部误修改原型状态，建议实现是“注册表返回克隆，原型本身不对外暴露”；
- 如果一个对象内部持有互斥锁、文件句柄等不可复制资源，不要天真地直接 clone，要么把这些资源单独隔离，要么 clone 后重新初始化；
- 如果对象依赖外部上下文（如网络连接、全局事件总线），克隆后要重新绑定，不能直接复制指针；
- 深拷贝的性能问题在超大对象上很现实，不该为了省代码把所有东西都深拷贝，该用独享引用的时候就用 shared_ptr，该共享的时候共享，要有区分。
写了很多，最后说一点个人体会。原型模式在 C++ 圈子里讨论度远不如单例、观察者那些“营销级”模式，很多人甚至觉得它无聊。但真正设计过图形系统、配置驱动的架构、或插件化产品之后，回头再看，会发现它是整个对象创建体系里被低估的核心支点。如果你正在维护一段充满了类型判断创建分支的老代码，不妨试着挑一个模块引入原型注册表，对比一下改动前后新增一个类型的成本，这种“脱胎换骨”的体验比看十篇教程都直观。
