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_ptrShape作为返回类型阻塞裸指针带来的所有权混乱这个问题放到后面第 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::vectorstd::unique_ptrShape shapes遍历时拿到的是Shape*你根本不知道背后是 Circle 还是 Rectangle。没有clone()你只能用 type() 判断然后强转类型再调用构造函数。这不就退回到文章开头那个 if-else 地狱了吗现在有了clone()客户代码长这样void duplicateShape(const Shape shape, std::vectorstd::unique_ptrShape 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_ptrImpl克隆时直接共享 Impl只有等某个对象要修改内部数据时才做一次真正的拷贝。文本编辑器的文档缓冲、图形引擎的顶点数据都大量使用这种手法。原型模式的clone()在毫秒级时间里返回一个共享内存的新对象而实际内容复制被推迟到真正需要的时候性能上非常可观。不过 CoW 也有自己的坑每个修改入口都要检查引用计数是否为 1忘记检查就会出现“改了这一个所有共享者全变了”的诡异行为。个人建议除非性能优化真的需要业务代码优先用朴素的深拷贝别为了省那点时间引入心智负担。4. 类型无关的工厂原型管理器与注册表如果你觉得原型模式的作用就是“复制对象”那还是把它看小了。原型模式真正的高级玩法是利用“原型对象本身作为工厂”这一特性实现一个不依赖 if-else 的对象创建注册表。这才是配置驱动、插件化架构的基石。标题里提到“原型设计模式”很多人在搜索时会把它和“工厂模式”搞混。区别在哪里工厂模式中一个工厂类负责创建多种对象通常还是需要知道具体类型而原型模式中对象自己充当自己的工厂调用方完全可以用一套通用代码接管所有类型的创建。两者并非互斥但原型模式在“运行时未知类型”这一点上有天然的压倒性优势。实现原型管理器第一件事是定义注册表。基于std::unordered_map或std::map键是对象类型标识值是原型对象class PrototypeRegistry { public: void registerPrototype(const std::string key, std::unique_ptrShape prototype) { prototypes_[key] std::move(prototype); } std::unique_ptrShape 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_ptrShape(it-second-clone()); } private: std::mapstd::string, std::unique_ptrShape prototypes_; };使用方式如下PrototypeRegistry registry; registry.registerPrototype(circle, std::make_uniqueCircle(5.0, 0.0, 0.0)); registry.registerPrototype(rect, std::make_uniqueRectangle(100.0, 50.0)); std::unique_ptrShape s1 registry.createClone(circle); // 得到一个圆 std::unique_ptrShape s2 registry.createClone(circle); // 再得到一个圆有没有注意到调用方从头到尾没有写过一次new Circle。以后你要新增一百种图形代码不需要做任何改动只需要注册即可。注册表模式的本质是把“哪个类型对应哪个创建逻辑”这张映射表从源码编译期转移到了运行期从而得到了一个非常宝贵的能力运行期动态扩展。最典型的应用就是插件系统。核心模块只定义 Shape 接口和注册表第三方插件拿到一个空注册表把自己实现的类注册进来。主程序通过配置文件里的字符串去查表、克隆根本不知道插件类头的路径。这就是原型模式与依赖解耦的最好示范。还有一个数据驱动对象创建的常见套路结合序列化可以做得非常漂亮std::unique_ptrShape 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_ptrT独占所有权明确转移高自动释放零默认首选std::shared_ptrT共享所有权高可能产生循环引用引用计数有开销需要共享生命周期时用先说为什么std::unique_ptrShape是首选。它表达的意思非常清楚clone()创建了一个新的、独立的对象这个对象的所有权完完全全交给了调用者。调用者拿到之后放入容器、传给其它函数、还是释放掉都是它的自由。没有共享歧义没有悬垂引用空间资源在离开作用域时自动回收。性能上和裸指针一模一样没有引用计数开销。写代码时这样定义接口class Shape { public: virtual ~Shape() default; virtual std::unique_ptrShape clone() const 0; virtual void draw() const 0; virtual std::string type() const 0; }; class Circle : public Shape { public: std::unique_ptrShape clone() const override { return std::make_uniqueCircle(*this); } // ... };这里有个细节。std::make_uniqueCircle(*this)直接调用拷贝构造函数正确又安全。如果 Circle 的拷贝构造实现的是深拷贝克隆出来的对象自然拥有独立资源。只改clone()签名整个调用链就安全了一大截void useShape(const Shape source) { auto copy source.clone(); // std::unique_ptrShape 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_ptrShape clone() const override { auto buffer std::make_uniquePixelBuffer(1024); auto shape std::make_uniqueCircle(*this, *buffer); // 任何一步抛异常之前分配的资源都会被自动清理 return shape; }代码稍微多一点但安全性从“碰运气”提升到了“随你怎么折腾都不泄漏”。做底层库的朋友应该深有体会类似这种多步资源分配的地方裸指针版本写一遍脑补一遍异常路径都要抖三抖智能指针版本是真的省心。那什么时候用std::shared_ptrShape当多个系统需要同时持有同一个克隆对象并协作修改它比如一个全局任务队列把自己的副本分享给多个消费者同时又不想随随便便复制一大块数据。这种情况下 shared_ptr 让所有权天然共享引用计数自动管理生命周期。代价是每次拷贝会增加一次原子计数操作这个开销在高频场景下能感受到但在多数业务代码里微乎其微。再补充一种更少见但实用的情况你的对象实现了原型模式同时也希望支持从外部给出来的另一个对象进行克隆。这时候可以用“外部源 转发构造”的方式在 clone 内部再套一层工厂函数。不过这种技巧非常看具体架构不是每种类型都适用这里不展开。内存安全这块还有一个容易忽略的地方——原型注册表本身持有的是 unique_ptr但拷贝语义和析构是不是对的一定要检查注册表插入原型时使用的构造方式。比如registerPrototype(circle, std::make_uniqueCircle(5.0, 0.0, 0.0))它创建的 Circle 对象被注册表独占。之后createClone返回的是std::unique_ptrShape注册表里的原型纹丝不动。等到整个 registry 析构时所有原型对象自动释放。这套生命周期非常干净不需要额外写析构逻辑。6. 应用场景实录从图形编辑器到游戏开发前面章节更多在讲“怎么实现原型模式”但不少读者可能更关心“它到底值不值得用”。我拿自己参与过或观察过的项目类型把原型模式的真实价值摊开来说。6.1 图形编辑器与文档系统复制粘贴的基石这类系统大概是原型模式最直观的受益者。用户选中任意图形、文本、图片框执行复制粘贴本质上就是一次“状态克隆”。如果只用构造函数你必须知道所有选中对象的精确类型然后逐个类型处理。用原型模式一个纯虚的clone()就可以覆盖所有对象新增一种对象也无需改动复制粘贴的核心流程。我印象很深的一次重构是在一个白板工具里。最开始复制一组元素用的是遍历字段硬拷贝代码写了一百多行而且经常漏拷贝“阴影偏移”“旋转角度”这类冷门字段。后来把每个元素类的clone()作为基础接口复制粘贴逻辑变成std::vectorstd::unique_ptrElement 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_ptrT因为所有权语义明确、异常安全如果多个对象需要共享克隆产物可以用std::shared_ptrT同时可以利用协变返回类型让派生类返回自身类型提升调用方便利性。能把 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 圈子里讨论度远不如单例、观察者那些“营销级”模式很多人甚至觉得它无聊。但真正设计过图形系统、配置驱动的架构、或插件化产品之后回头再看会发现它是整个对象创建体系里被低估的核心支点。如果你正在维护一段充满了类型判断创建分支的老代码不妨试着挑一个模块引入原型注册表对比一下改动前后新增一个类型的成本这种“脱胎换骨”的体验比看十篇教程都直观。