原型模式通过克隆现有对象来创建新对象，避免重复构造。在JavaScript中，利用Object.create()实现原型继承，新对象继承原型的属性和方法，并可通过原型链查找。相比工厂模式（关注抽象创建）和单例模式（确保唯一实例），原型模式强调复制与模板复用。其核心优势在于解耦对象创建，提升灵活性。在Java、C#中通过Cloneable接口和clone()方法实现，需手动处理深拷贝；Python则用copy模块支持浅拷贝与深拷贝。原型模式体现委托思想，适用于需动态创建或高成本实例化的场景，但需警惕引用共享和原型链污染问题。
原型模式，在我看来，它是一种相当优雅且灵活的对象创建方式，核心思想就是“克隆”：不通过传统的构造函数来创建新对象，而是复制一个已有的对象（我们称之为“原型”）。这在JavaScript里体现得淋漓尽致，因为JavaScript本身就是基于原型的语言，它的继承机制，也就是所谓的“原型继承”，正是这种模式的自然产物。简单说，当你想创建一个新对象，并且这个新对象和某个已有对象有很多共同点时，直接复制那个已有对象会比从头构建来得更直接、更省心。
解决方案
原型模式的核心在于通过复制现有对象来创建新对象，从而避免了子类化或显式调用构造函数。在JavaScript中，这意味着我们经常会利用
Object.create()方法。当你有一个对象
A，想基于它创建一个新对象
B，让
B能访问
A的所有属性和方法，同时又可以有自己的特定属性，那么
Object.create(A)就是最直接的实现方式。新创建的
B会把
A作为它的原型，这意味着
B会通过原型链向上查找
A上的属性和方法。这种方式在处理大量相似对象，或者需要运行时动态地决定对象类型时，显得尤为高效和简洁。它减少了对具体类的依赖，让代码更加灵活。
原型模式与工厂模式、单例模式有何区别？
说实话，很多人初学设计模式时，会把这些创建型模式搞混，觉得它们都是用来“创建对象”的。但它们的侧重点和解决的问题完全不同。
原型模式，它关心的是“如何通过复制现有对象来创建新对象”，强调的是“克隆”和“模板”。你有一个现成的“样板间”（原型对象），然后根据这个样板间批量复制出新的房间，这些新房间自带样板间的所有基础结构，你再按需进行个性化装修。它的核心在于避免直接实例化，而是通过复制操作来解耦创建过程。
工厂模式呢，它更像是一个“生产线”，或者说一个“代工厂”。你告诉它你需要什么类型的产品（比如“生产一辆轿车”），它就负责帮你生产出来，至于里面具体是哪个品牌、哪个型号，你可能不需要关心，或者说工厂内部有一套逻辑来决定。它抽象了对象的创建过程，让你不需要知道具体的构造函数或类名。关注点在于“生产什么类型的产品”，而不是“怎么复制一个产品”。
至于单例模式，它的目标就更明确了：确保某个类在整个系统中只有一个实例。就像公司的CEO，不管你通过什么方式去“获取”他，最终指向的都是同一个人。它关注的是“只存在一个实例”，通常用于配置管理器、日志记录器等需要全局唯一访问的场景。
所以，它们虽然都涉及对象创建，但解决的问题、实现方式和应用场景都大相径庭。原型模式强调的是“复制”，工厂模式强调的是“抽象生产”，而单例模式强调的是“唯一性”。
在JavaScript中，原型继承的实现细节和潜在陷阱是什么？
JavaScript的原型继承，从ES6的
class语法糖出现后，表面上看起来和传统的面向对象语言的继承很像，但底层逻辑依旧是原型链。最常见的实现方式，除了前面提到的
Object.create()，还有一种比较“老派”的做法，就是直接把父类的实例赋值给子类的
prototype属性。比如：
Child.prototype = new Parent();。这种方式虽然能实现继承，但有个明显的“坑”：
Parent的构造函数会被调用一次，而且如果
Parent的实例上有引用类型（比如数组或对象），那么所有
Child的实例都会共享这个引用，一个实例修改了，其他实例也会受影响，这就是所谓的“浅拷贝”问题。此外，
Child.prototype.constructor会指向
Parent，需要手动修复为
Child，否则会有些奇怪的行为。
相比之下，
Object.create()就优雅多了。
Child.prototype = Object.create(Parent.prototype);这样只继承了原型上的方法，避免了父类构造函数的额外调用，也减少了共享引用类型带来的副作用。当然，
constructor属性的问题依然存在，需要手动设置
Child.prototype.constructor = Child;。
另一个潜在的陷阱是“原型链污染”。如果你的代码允许用户输入的数据直接修改对象原型上的属性，就可能导致整个应用的行为被意外改变。这在处理JSON数据或进行数据合并时尤其需要注意，要避免直接操作
__proto__或者不加校验地合并对象。
说到底，原型继承的核心是“委托”：当一个对象找不到某个属性或方法时，它会委托给它的原型去查找，直到原型链的顶端（通常是
Object.prototype）。理解这一点，就能更好地驾驭JavaScript的对象和继承。
除了JavaScript，原型模式在其他编程语言或设计模式中是如何体现的？
原型模式并非JavaScript独有，它是一个在软件工程领域广泛应用的设计模式，由GoF（Gang of Four）在《设计模式》一书中明确提出。在其他一些静态类型语言中，虽然没有JavaScript那样原生的“原型链”概念，但“通过复制现有对象来创建新对象”的理念依然存在。
比如在Java或C#这类语言中，要实现原型模式，通常会用到
Cloneable接口和
clone()方法。你需要让你的类实现
Cloneable接口，并重写
clone()方法。这个
clone()方法通常会调用
super.clone()来执行浅拷贝，如果对象内部包含引用类型的成员变量，并且你需要深拷贝（即复制这些引用类型本身而不是仅仅复制它们的引用），那么你就需要在
clone()方法中手动地对这些成员进行递归克隆。这比JavaScript的原型机制要显得“重”一些，需要更多的显式代码来管理复制过程，特别是深拷贝的实现，往往是开发者需要自己去操心的。
Python虽然是动态语言，但它的对象复制也主要通过
copy模块的
copy.copy()（浅拷贝）和
copy.deepcopy()（深拷贝）函数来实现。这里的核心思想也是基于现有对象创建新对象，而不是从类定义重新实例化。
从更广阔的设计模式角度看，原型模式体现了一种“基于委托的编程风格”，而不是传统的“基于类的编程风格”。它鼓励我们思考如何通过已有的实例来构建新的实例，而不是总是从零开始定义一个类。这种思想在需要动态地创建对象、避免与具体类耦合、或者对象创建成本较高时，显得尤为有用。它提供了一种灵活的替代方案，让系统在运行时能够根据需要“复制”出新的行为和状态。
