1. 先聊聊“家族关系”这个比喻怎么来的JavaScript 的原型和原型链几乎每个前端开发者在学了一段时间之后都会撞上这堵墙。你搜索“原型链面试题”能翻出一大堆笔记和图解但很多人看完依然是一脸茫然——prototype、__proto__、constructor三个东西似乎都长得差不多绕来绕去分不清谁是谁。我教过不少刚入行的开发者发现大家卡住的原因往往不是“概念太抽象”而是脑袋里没有一张清晰的图。今天这篇博文我想用一种特别直观的方式把整条链路讲清楚——我把它叫作“家族谱系法”。简单来说JavaScript 里的每个对象都不是孤零零站着的。它身上挂着一个隐式的指针指向“生出它的那个人”。比如const a {}创建出来的 a它内部就记住了一句话“我的父辈是Object.prototype”。如果你去访问a.toString()a 自己身上没有这个方法它就会顺着这个父辈指针往上找父辈也没有就找父辈的父辈一路追到老祖宗。这个过程就是“原型链查找”。理解这一点之后后面所有的东西——继承、new的原理、instanceof的判定规则、甚至class语法糖底层做了什么事——都会像多米诺骨牌一样一张接一张倒下迎刃而解。这篇文章我打算分成六个部分从最基础的“谁是爸爸”讲到高级的“继承方案选型”中间会穿插大量可以直接跑的示例代码以及我自己在实际项目中踩过的坑。无论你是刚接触原型链的新手还是已经工作两年但一直没有系统梳理过这个知识点的进阶开发者这篇文章都值得你花半小时完整读一遍。最后说一句不要指望一次背完所有图解而是跟着代码亲手敲一遍打印出每一个对象的__proto__和constructor你会有一种“原来如此”的通透感。2. 揭开原型的面纱每个函数都自带“生育模板”2.1 三条铁律从零开始建立正确认知要理解原型链我建议先把三条铁律刻在脑子里。这三条不是我编的是整个语言在设计之初就定好的底层规则理解了它们你甚至可以脱离图解直接手推原型链。铁律一一切对象包括函数对象都有__proto__属性这个属性指向创建它的那个构造函数的prototype。铁律二一切函数普通函数、构造函数、class都有prototype属性这个属性是一个对象叫“原型对象”。铁律三Function.prototype比较特殊它是一个“空函数”同时它自己的__proto__指向一个叫Object.prototype的存在。而Object.prototype是整个链条的终点它的__proto__是null。光看这三条你可能会觉得“这跟我平时写的代码有什么关系”先别急我用一个很生活化的例子来解释。想象一下你所在的家族有一本厚厚的族谱族谱的正本放在家族祠堂里所有人都能查阅。这本书就是“原型对象”——构造函数.prototype。每个家族成员出生的时候虽然没有亲手拿到这本书的复印版但每个人都有资格去翻阅它。如果你问某个成员“你家祖上有什么传统”他自己答不上来就会去祠堂翻那本族谱。如果他爸爸也不会那就顺着族谱去问他爷爷。问到最后族谱最后一页写着“本族起源不详”再往上就没有了。在 JavaScript 里某个实例对象调用方法时先在自己身上找找不到就走__proto__找到构造函数的prototype对象再找不到就沿着prototype对象的__proto__继续往上最后摸到Object.prototype。Object.prototype的__proto__是null这就是“问无可问”的终点。2.2 用一个函数“造出三个人”观察血缘关系理论说完直接上代码。我定义一个构造函数Person然后用它创建三个实例。function Person(name, age) { this.name name; this.age age; } Person.prototype.sayHello function () { console.log(大家好我叫${this.name}今年${this.age}岁); }; const ming new Person(小明, 18); const hong new Person(小红, 20); const gang new Person(小刚, 22); ming.sayHello(); // 大家好我叫小明今年18岁 hong.sayHello(); // 大家好我叫小红今年20岁这里有一个非常关键的点sayHello这个方法并没有在 ming、hong、gang 自己身上而是挂在Person.prototype上。但你依然可以通过实例调用到它这就是原型链查找在起作用。我们可以打印一下这些对象的关系验证刚才说的铁律console.log(ming.__proto__ Person.prototype); // true console.log(gang.__proto__ Person.prototype); // true console.log(Person.prototype.__proto__ Object.prototype); // true console.log(Object.prototype.__proto__ null); // true console.log(ming instanceof Person); // true console.log(ming instanceof Object); // true这里我建议读者亲手敲一遍把每一行输出都仔细看一遍尤其是ming instanceof Object为true这一点。很多人会奇怪ming明明是Person造出来的为什么跟Object也有关系因为在原型链上Person.prototype本身也是一个普通对象它的__proto__指向的是Object.prototype所以顺着链子一直往上摸终究能摸到Object的地盘。也就是说任何一个普通对象最终都能通过原型链与Object.prototype建立联系这就是为什么数组、函数、类实例都可以调用toString、hasOwnProperty这些通用方法。2.3 为什么要有原型直接复制一份方法到每个实例上不行吗这个问题在我带新人的时候几乎必被问。答案也很直接费内存且失去了动态性。如果不用原型而是把方法直接复制到每个实例上const obj1 { greet: function () { console.log(hi) } }; const obj2 { greet: function () { console.log(hi) } };做法上的确可行但 obj1 和 obj2 各自保存了一份 greet 函数的内存副本。如果有十万个实例就得存十万份功能一模一样的函数这在内存上是巨大浪费。而挂在原型上十万个实例共享同一个prototype对象里的同一个方法内存上只占一份。再说动态性。原型上的方法可以在运行时统一给所有实例“升级能力”。比如我写了一个构造函数Car所有汽车实例都通过原型链拿到了run方法。过了一阵子老板说需要在所有汽车上增加stop方法。我只需要在Car.prototype上添加一个方法所有已有实例立刻就拥有了这个方法不用一个一个去更新。这种“集体升级”的能力正是原型机制给开发者的最大红利。注意虽然原型带来便利但频繁修改内置对象如Array.prototype、Object.prototype是非常危险的做法可能在团队协作或第三方库冲突时带来难以排查的问题。后面会详细讲这个坑。3. 原型链上的“三角关系”函数、原型对象、实例对象3.1 谁是谁的父亲一张极简关系图带你少走弯路到了这一步你应该已经清楚实例和构造函数原型之间的关系了。但 JavaScript 里真正的难点在于函数本身也是对象所以函数也有__proto__。这就导致整个链路图上出现了很多交叉箭头很多新手就是在这里迷失方向的。我自己整理了一套非常简单的记忆方法一共四句话实例对象的__proto__指向其构造函数的prototype。构造函数的prototype对象里有一个constructor属性指向构造函数自己。构造函数作为对象的__proto__指向Function.prototype。Function.prototype的__proto__指向Object.prototype。请记住以上四句话就是整个 JavaScript 原型体系的骨架。咱们逐条验证一下function Foo() {} const foo new Foo(); // 第一句实例走向构造函数的原型 console.log(foo.__proto__ Foo.prototype); // true // 第二句原型对象里有个 constructor 指回构造函数 console.log(Foo.prototype.constructor Foo); // true // 第三句构造函数函数对象的 __proto__ 指向 Function.prototype console.log(Foo.__proto__ Function.prototype); // true // 第四句Function.prototype 的 __proto__ 指向 Object.prototype console.log(Function.prototype.__proto__ Object.prototype); // true这四句话里最难理解的是第三句。它的含义是Foo虽然是你自定义的构造函数但它本身也是被Function这个内置构造函数“造”出来的所以它的__proto__指向Function.prototype。同样的道理Object本身也是一个函数所以Object.__proto__ Function.prototype也是 true。甚至Function.__proto__ Function.prototype也是 true。3.2 对象的原型链终点为什么是 null接着上一节很多读者会问为什么Object.prototype.__proto__是null而不是别的从设计哲学上讲null就代表“这里没有了”。原型链是一个有限长度的链条必须有一个明确的“尽头”否则查找方法的时候会陷入无限的循环。Object.prototype是普通对象的“老祖宗”它再往上的父辈已经没有实际意义了所以语言标准规定它的__proto__必须为null。你试一下运行const obj {}; console.log(obj.__proto__ Object.prototype); // true console.log(Object.getPrototypeOf(Object.prototype)); // null在绝大多数日常业务代码中普通对象的原型链最多也就是obj → Object.prototype → null这么短。但由类实例化出来的对象链条会长一些比如class Animal {} class Dog extends Animal {} const dog new Dog(); // dog - Dog.prototype - Animal.prototype - Object.prototype - null console.log(dog.__proto__ Dog.prototype); console.log(Dog.prototype.__proto__ Animal.prototype); console.log(Animal.prototype.__proto__ Object.prototype); console.log(Object.prototype.__proto__ null);你可以把这个链条想象成一条从具体到抽象的线索最具体的狗依次到狗这个类、动物这个类、再到所有对象的根基Object.prototype最后到 null 完结。这种链式结构正是 JavaScript 实现继承与共享的核心机制。从事后来看正确理解这条链对日常工作有什么实实在在的好处我举一个最常见的例子当你使用某个第三方库的对象时想给它额外扩展一个方法你会写obj.customMethod function(){}。如果只对某一个实例操作那没问题但如果希望所有同类对象都拥有这个方法就应该把它加到该对象所属类的prototype上而不是每个实例单独加。理解原型链你才知道哪些方法应该加在哪儿。3.3 手写 instanceof从根部理解判定规则instanceof也是面试和开发中的高频操作符它判断的是“实例的原型链上是否存在某个构造函数的prototype对象”。很多文章只告诉你怎么用却没有深入讲它的判定逻辑。其实手写一个简易版非常容易而且能顺便加深你对原型链的认识function myInstanceof(instance, constructor) { // 基本类型直接返回 false if (typeof instance ! object typeof instance ! function) { return false; } let proto Object.getPrototypeOf(instance); const prototypeObj constructor.prototype; while (proto ! null) { if (proto prototypeObj) { return true; } proto Object.getPrototypeOf(proto); } return false; } const arr []; console.log(myInstanceof(arr, Array)); // true console.log(myInstanceof(arr, Object)); // true console.log(myInstanceof([], String)); // false这段代码的逻辑非常直白从实例的__proto__出发一路用Object.getPrototypeOf往上爬每爬一层就对比一次直到找到跟构造函数的prototype相等的对象或者爬到null而失败。这里有一个实际开发中容易踩到的坑如果你自己改写了某个对象的__proto__指向instanceof的结果也会随之变化。极端情况下有人为了某种 hack 把对象的__proto__改成了null那它跟任何类都不再存在instanceof关系。这种操作非常危险极容易导致代码行为不可预期。4. 创建对象时到底发生了什么new 操作符与 constructor 背后的真实逻辑4.1 在做项目之前你需要真正理解 new 的四个步骤很多开发者每天都在写new但你要问他在new背后 JavaScript 干了什么事他一般会沉默。其实new的原生执行过程可以拆成四步创建一个全新的空对象。将这个新对象的__proto__指向构造函数的prototype对象。调用构造函数并将构造函数的this绑定到这个新对象上执行函数体代码比如给 this 挂属性。如果构造函数默认返回了一个对象那就用这个对象否则返回新创建的对象。注意第四步有个微妙之处如果构造函数内部显式return了一个普通对象那么new的结果会变成你return的那个对象而不是新创建的对象。但如果你 return 的是一个基本类型比如数字、字符串则会被忽略仍然返回新对象。来看一个经典案例function Person(name) { this.name name; return { nickName: 化名 }; } const p new Person(小明); console.log(p.name); // undefined console.log(p.nickName); // 化名构造函数返回了对象字面量new 出来的人就没有 name 属性。这在真实项目中并不常见但假如你去读某些封装库源码可能会看到利用这个特性做“工厂模式”的写法。为了加深理解我手写一个简易版myNew你可以在本地运行对比效果function myNew(constructor, ...args) { // 第一步创建一个空对象并把原型指向 constructor.prototype const obj Object.create(constructor.prototype); // 第三步以 obj 为 this 执行构造函数 const result constructor.apply(obj, args); // 第四步如果构造函数返回是对象则返回这个对象否则返回 obj return result (typeof result object || typeof result function) ? result : obj; } function Animal(name) { this.name name; } Animal.prototype.speak function () { console.log(${this.name} 在叫); }; const dog myNew(Animal, 旺财); console.log(dog.name); // 旺财 dog.speak(); // 旺财 在叫 console.log(dog instanceof Animal); // true通过手写 new你能更清楚地知道实例身上为什么会有构造函数的属性因为执行了原型上的方法绑定过程也更能理解为什么说“构造函数中的 this 就是未来的实例对象”。4.2 一个面试题引发的思考constructor 到底可不可靠关于constructor属性有一个高频面试题function A() {} const a new A(); console.log(a.constructor A); // true console.log(a.constructor A.prototype.constructor); // true这个结果成立是因为a自身没有constructor属性于是沿原型链找到A.prototype.constructor它指向 A。看起来一切正常。但假如你在代码里不小心改写了A.prototype呢function A() {} A.prototype { custom: true }; const a new A(); console.log(a.constructor A); // false console.log(a.constructor); // Object看到了吗当你整体替换A.prototype时新的原型对象上默认没有constructor属性此时a.constructor会顺着链条继续往上找到Object.prototype.constructor也就是Object。这就是一个典型的“constructor 不可靠”场景。正确的做法是每次整体替换prototype之后手动补回constructor指向保持关系链不破function A() {} A.prototype { custom: true }; A.prototype.constructor A; const a new A(); console.log(a.constructor A); // true老实说这个点在实际业务开发中极少触发但踩过坑的人都知道当你在做组件二次封装或写底层库时原型链的完整性极其重要。破坏一个 constructor 指向可能导致很多依赖instanceof或constructor的类型判断代码静默失败且特别难追踪定位。5. 继承如何把“家族财产”优雅地传承下去5.1 别再用组合继承的“错误姿势”了JavaScript 的继承有很多种写法但万变不离其宗——本质上都是在操纵“原型链的指向”。我们先把最经典、早期教科书中常见的“组合继承”拿出来看function Parent(name) { this.name name; this.hobbies [看书, 运动]; } Parent.prototype.sayName function () { console.log(this.name); }; function Child(name, age) { Parent.call(this, name); // 第一次继承父类实例属性 this.age age; } Child.prototype new Parent(); // 第二次继承父类原型方法 Child.prototype.constructor Child; const kid1 new Child(小明, 8); const kid2 new Child(小红, 10); kid1.hobbies.push(画画); console.log(kid1.hobbies); // [看书, 运动, 画画] console.log(kid2.hobbies); // [看书, 运动]两个实例互不影响组合继承确实是可用的但它有一个被反复诟病的问题Parent被调用了两次。第一次是在Child内部通过Parent.call(this, name)把父类实例属性复制到子类实例上第二次是在Child.prototype new Parent()创建原型对象时又让 Parent 的构造函数执行了一遍于是Child.prototype上多出一份没用的 name 和 hobbies 属性。这份属性既不会被子类实例使用因为实例自己已经有了又白白占着内存。5.2 寄生组合式继承面试与实战的“标准答案”后来业界渐渐统一推荐使用“寄生组合式继承”核心思路是利用一个空函数做桥梁让子类原型直接连接到父类原型而不是通过执行父类构造函数来生成子类原型。经典写法如下function inheritPrototype(Child, Parent) { const prototype Object.create(Parent.prototype); prototype.constructor Child; Child.prototype prototype; } function Parent(name) { this.name name; } Parent.prototype.sayName function () { console.log(this.name); }; function Child(name, age) { Parent.call(this, name); this.age age; } inheritPrototype(Child, Parent); Child.prototype.sayAge function () { console.log(this.age); }; const child new Child(小明, 8); console.log(child instanceof Parent); // true console.log(child instanceof Child); // true child.sayName(); // 小明 child.sayAge(); // 8这段代码的关键在于Object.create(Parent.prototype)它会返回一个新对象该新对象的__proto__指向Parent.prototype。然后我们把这个新对象指派给Child.prototype并补回constructor指向Child。这种方案的巧妙之处在于不会执行父类构造函数只在原型层面建立父子链接。父类实例属性通过Parent.call一次性复制到子类实例上原型上的公共方法则通过链式共享。这就是“寄生组合式继承”被公认为最佳组合继承方案的原因。你会注意到上面这段代码其实就是一个简化版 ES6class继承的底层原理。当你编写class Child extends Parent {}时JavaScript 引擎做的事情与寄生组合式继承的思路几乎一致。5.3 class 继承的真身extends 背后的原型链操作很多新人不理解为什么 class 继承看起来跟函数构造继承差别很大其实底层完全一样class 只是语法糖。看下面这个例子class Animal { constructor(name) { this.name name; } eat() { console.log(${this.name} 在吃饭); } } class Dog extends Animal { constructor(name, breed) { super(name); this.breed breed; } bark() { console.log(${this.name} 在汪汪叫); } } const dog new Dog(旺财, 金毛); dog.eat(); // 旺财 在吃饭 dog.bark(); // 旺财 在汪汪叫 console.log(dog instanceof Dog); // true console.log(dog instanceof Animal); // true console.log(Dog.prototype.__proto__ Animal.prototype); // true关键就是最后一行Dog.prototype.__proto__ Animal.prototype。这意味着 Dog 的实例不仅可以在 Dog.prototype 上找方法还可以顺着链子走到 Animal.prototype 上找方法。所以 Dog 的实例能调用 eat本质上是因为 eat 存在于 Animal.prototype 上而 Dog.prototype 的原型就是 Animal.prototype。super(name)的作用也很有趣它在底层就是类似Animal.call(this, name)的过程不过它还会做一件事——让这个方法调用时的this正确指向当前实例同时保证能够继续访问父类原型上的方法。关于 class 继承有一个经典面试题super是否必须写在 constructor 第一行其实不必“必须第一行”但在 super 调用之前不能访问this。因为引擎需要先调用父类构造函数完成实例属性和 this 的初始化之后才能让子类去添加自己的属性。如果你反过来写就会报 “Must call super constructor in derived class before accessing this or returning from derived constructor” 的错误。5.4 各继承方案对比与选型建议写代码这么多年我的经验是日常业务开发直接使用 ES6 的class语法就够了不要自己手写各种偏门继承组合。但如果你在阅读源码或维护老项目看到经典组合继承、原型链继承这些写法得能一眼看出来它们的问题在哪儿。这里给大家整理一份我在内部培训时常用的对比表继承方案实现要点优点缺点应用建议原型链继承子类原型直接指向父类实例写法简单多个实例共享父类引用类型属性互相污染不推荐单独使用借用构造函数继承在子类中调用父类构造函数实例属性完全隔离不能获取父类原型上的方法极少单独使用组合继承构造函数继承 原型链继承属性隔离且方法共享父类构造函数被调用两次老项目遇到能看懂即可寄生组合式继承用空对象承接父类原型无多余调用性能最佳写法稍复杂适合手写底层类库ES6 class 继承extends super语义清晰官方推荐旧浏览器需转译日常开发首选在选型上我的建议很明确团队新项目一律用 class 继承不要搞“为了炫技而炫技”的继承组合。JavaScript 的继承能力本身不算弱但继承层级过深会导致代码难以理解和维护。很多时候组合优于继承能用函数组合、依赖注入解决的问题不要硬生生搞出五层原型链。6. 快速判断与实用技巧从原型链的角度优化你的日常开发6.1 三种方式检查属性归属in、hasOwnProperty、Object.keys在写代码时我们经常需要判断一个属性是否存在于对象身上。但这个“存在”有两种截然不同的含义一种是指“原型链上能看到”另一种是“对象自己所有”。二者之间的差异用in操作符和hasOwnProperty就能区分。function Person() {} Person.prototype.name 某人; const p new Person(); console.log(name in p); // true因为原型链上有 console.log(p.hasOwnProperty(name)); // false因为不是自己的属性 console.log(Object.keys(p)); // []只列自身可枚举属性再举一个实际项目里的常见场景你要遍历一个从后端拿到的数据对象只想输出对象自己拥有的字段不想输出从Object.prototype继承来的方法。这个时候就应该用hasOwnProperty做一层过滤否则可能不小心把toString、valueOf等原型方法也打印出来。还有一个大家可能没注意到的冷知识Object.keys()只返回自身的可枚举属性而for...in会同时遍历原型链上的可枚举属性。因此在for...in循环内部通常建议配合hasOwnProperty使用避免可继承的可枚举属性干扰业务逻辑。Object.prototype.customTag global; const obj { a: 1 }; for (const key in obj) { console.log(key); // 输出 a也输出 customTag } for (const key in obj) { if (obj.hasOwnProperty(key)) { console.log(key); // 只输出 a } }我见过有人在业务代码里忘了这种区别导致for...in遍历时突然多出来一些莫名其妙的字段最后排查半天才发现是某个工具库动过Object.prototype。所以一个基本的开发素养永远不要在运行时去污染内置原型。6.2 使用 Object.create 实现“干净”的对象和极简原型链控制Object.create是一个极其强大但经常被忽略的方法。它接受两个参数第一个是原型对象第二个是属性描述对象。它可以让你精准控制新对象的__proto__指向非常适合用来实现继承关系、或创建“没有原型”的纯粹字典对象。const base { version: 1.0, getVersion() { return this.version; } }; const child Object.create(base); child.name 子对象; console.log(child.name); // 子对象 console.log(child.getVersion()); // 1.0来自原型链 console.log(Object.getPrototypeOf(child) base); // true再比如创建一个完全空白的对象没有任何原型链干扰const pureObj Object.create(null); console.log(Object.getPrototypeOf(pureObj)); // null console.log(pureObj.toString); // undefined因为没有任何原型方法这种pureObj特别适合用作 Map 出现之前的“纯字典结构”你不用担心它的 key 会不会跟原型上的方法名冲突。比如你想存一个{ toString: 自定义 }在普通对象上会导致原型方法被遮蔽但用Object.create(null)就不会有任何问题。不过要注意纯空对象无法调用hasOwnProperty、toString等方法若需要检测属性得借助Object.prototype.hasOwnProperty.call(pureObj, key)这种方式。另外Object.create(null)在很多框架源码里常被用来创建所谓“守卫对象”可以避免原型链干扰。这个技巧虽然小众一旦用对地方效果奇佳。6.3 开发中的避坑指南黑魔法尽量不要碰最后必须严肃地聊一聊“修改原型链”这类黑魔法的边界。虽然 JavaScript 允许你直接改写任意对象的__proto__也可以给Array.prototype挂挂载方法但我个人强烈不建议在业务代码中这么干。原因有三点一是性能开销。现代 JavaScript 引擎对对象属性访问做了大量优化前提是对象结构稳定。如果你频繁改变__proto__引擎无法做内联缓存访问属性的性能会显著下降。在某些性能敏感的页面里这种改动可能带来肉眼可见的卡顿。二是可维护性灾难。一旦你改了内置原型团队所有人都受影响。别人写for...in时可能突然多出你挂的方法别人使用Array.map时可能触发你重写过的版本而这些“隐性行为”在代码评审里极难被察觉。三是规范化趋势。ECMAScript 标准对新语法和内置对象的改动已经越来越克制官方也不建议开发者自行扩展全局对象。像Array.prototype.flat、Object.hasOwn这类新特性都是语言规范亲自实现而不是鼓励大家自己往原型上添加。话说回来理解__proto__的作用仍然很有必要尤其是调试环节。比如你用console.dir打印一个复杂对象时Chrome DevTools 会展示出__proto__链条你能一眼看出这个对象从哪个类来、继承了哪些属性和方法。这种排查问题的方式比单纯看报错信息更高效。写到这里我不禁回想起自己刚学 JavaScript 时完全被原型链绕进去的那段日子。有一次在项目里排查 bug发现某个组件拿到的数据对象多了一个方法怎么都找不到是谁加上的。后来用console.dir一层层展开__proto__才发现是某段公共代码往Object.prototype上挂了一个全局方法问题瞬间清楚了。从此以后我对原型链的态度是理解它、敬畏它、不乱动它。希望这篇“家族关系大揭秘”能让你看清楚原型链的本质它不仅是 JavaScript 实现复用的核心机制更是理解继承、new、instanceof、class的一把万能钥匙。把这条链子理顺了再看任何框架的源码你都会有底气得多的底气。
1. 先聊聊“家族关系”这个比喻怎么来的JavaScript 的原型和原型链几乎每个前端开发者在学了一段时间之后都会撞上这堵墙。你搜索“原型链面试题”能翻出一大堆笔记和图解但很多人看完依然是一脸茫然——prototype、__proto__、constructor三个东西似乎都长得差不多绕来绕去分不清谁是谁。我教过不少刚入行的开发者发现大家卡住的原因往往不是“概念太抽象”而是脑袋里没有一张清晰的图。今天这篇博文我想用一种特别直观的方式把整条链路讲清楚——我把它叫作“家族谱系法”。简单来说JavaScript 里的每个对象都不是孤零零站着的。它身上挂着一个隐式的指针指向“生出它的那个人”。比如const a {}创建出来的 a它内部就记住了一句话“我的父辈是Object.prototype”。如果你去访问a.toString()a 自己身上没有这个方法它就会顺着这个父辈指针往上找父辈也没有就找父辈的父辈一路追到老祖宗。这个过程就是“原型链查找”。理解这一点之后后面所有的东西——继承、new的原理、instanceof的判定规则、甚至class语法糖底层做了什么事——都会像多米诺骨牌一样一张接一张倒下迎刃而解。这篇文章我打算分成六个部分从最基础的“谁是爸爸”讲到高级的“继承方案选型”中间会穿插大量可以直接跑的示例代码以及我自己在实际项目中踩过的坑。无论你是刚接触原型链的新手还是已经工作两年但一直没有系统梳理过这个知识点的进阶开发者这篇文章都值得你花半小时完整读一遍。最后说一句不要指望一次背完所有图解而是跟着代码亲手敲一遍打印出每一个对象的__proto__和constructor你会有一种“原来如此”的通透感。2. 揭开原型的面纱每个函数都自带“生育模板”2.1 三条铁律从零开始建立正确认知要理解原型链我建议先把三条铁律刻在脑子里。这三条不是我编的是整个语言在设计之初就定好的底层规则理解了它们你甚至可以脱离图解直接手推原型链。铁律一一切对象包括函数对象都有__proto__属性这个属性指向创建它的那个构造函数的prototype。铁律二一切函数普通函数、构造函数、class都有prototype属性这个属性是一个对象叫“原型对象”。铁律三Function.prototype比较特殊它是一个“空函数”同时它自己的__proto__指向一个叫Object.prototype的存在。而Object.prototype是整个链条的终点它的__proto__是null。光看这三条你可能会觉得“这跟我平时写的代码有什么关系”先别急我用一个很生活化的例子来解释。想象一下你所在的家族有一本厚厚的族谱族谱的正本放在家族祠堂里所有人都能查阅。这本书就是“原型对象”——构造函数.prototype。每个家族成员出生的时候虽然没有亲手拿到这本书的复印版但每个人都有资格去翻阅它。如果你问某个成员“你家祖上有什么传统”他自己答不上来就会去祠堂翻那本族谱。如果他爸爸也不会那就顺着族谱去问他爷爷。问到最后族谱最后一页写着“本族起源不详”再往上就没有了。在 JavaScript 里某个实例对象调用方法时先在自己身上找找不到就走__proto__找到构造函数的prototype对象再找不到就沿着prototype对象的__proto__继续往上最后摸到Object.prototype。Object.prototype的__proto__是null这就是“问无可问”的终点。2.2 用一个函数“造出三个人”观察血缘关系理论说完直接上代码。我定义一个构造函数Person然后用它创建三个实例。function Person(name, age) { this.name name; this.age age; } Person.prototype.sayHello function () { console.log(大家好我叫${this.name}今年${this.age}岁); }; const ming new Person(小明, 18); const hong new Person(小红, 20); const gang new Person(小刚, 22); ming.sayHello(); // 大家好我叫小明今年18岁 hong.sayHello(); // 大家好我叫小红今年20岁这里有一个非常关键的点sayHello这个方法并没有在 ming、hong、gang 自己身上而是挂在Person.prototype上。但你依然可以通过实例调用到它这就是原型链查找在起作用。我们可以打印一下这些对象的关系验证刚才说的铁律console.log(ming.__proto__ Person.prototype); // true console.log(gang.__proto__ Person.prototype); // true console.log(Person.prototype.__proto__ Object.prototype); // true console.log(Object.prototype.__proto__ null); // true console.log(ming instanceof Person); // true console.log(ming instanceof Object); // true这里我建议读者亲手敲一遍把每一行输出都仔细看一遍尤其是ming instanceof Object为true这一点。很多人会奇怪ming明明是Person造出来的为什么跟Object也有关系因为在原型链上Person.prototype本身也是一个普通对象它的__proto__指向的是Object.prototype所以顺着链子一直往上摸终究能摸到Object的地盘。也就是说任何一个普通对象最终都能通过原型链与Object.prototype建立联系这就是为什么数组、函数、类实例都可以调用toString、hasOwnProperty这些通用方法。2.3 为什么要有原型直接复制一份方法到每个实例上不行吗这个问题在我带新人的时候几乎必被问。答案也很直接费内存且失去了动态性。如果不用原型而是把方法直接复制到每个实例上const obj1 { greet: function () { console.log(hi) } }; const obj2 { greet: function () { console.log(hi) } };做法上的确可行但 obj1 和 obj2 各自保存了一份 greet 函数的内存副本。如果有十万个实例就得存十万份功能一模一样的函数这在内存上是巨大浪费。而挂在原型上十万个实例共享同一个prototype对象里的同一个方法内存上只占一份。再说动态性。原型上的方法可以在运行时统一给所有实例“升级能力”。比如我写了一个构造函数Car所有汽车实例都通过原型链拿到了run方法。过了一阵子老板说需要在所有汽车上增加stop方法。我只需要在Car.prototype上添加一个方法所有已有实例立刻就拥有了这个方法不用一个一个去更新。这种“集体升级”的能力正是原型机制给开发者的最大红利。注意虽然原型带来便利但频繁修改内置对象如Array.prototype、Object.prototype是非常危险的做法可能在团队协作或第三方库冲突时带来难以排查的问题。后面会详细讲这个坑。3. 原型链上的“三角关系”函数、原型对象、实例对象3.1 谁是谁的父亲一张极简关系图带你少走弯路到了这一步你应该已经清楚实例和构造函数原型之间的关系了。但 JavaScript 里真正的难点在于函数本身也是对象所以函数也有__proto__。这就导致整个链路图上出现了很多交叉箭头很多新手就是在这里迷失方向的。我自己整理了一套非常简单的记忆方法一共四句话实例对象的__proto__指向其构造函数的prototype。构造函数的prototype对象里有一个constructor属性指向构造函数自己。构造函数作为对象的__proto__指向Function.prototype。Function.prototype的__proto__指向Object.prototype。请记住以上四句话就是整个 JavaScript 原型体系的骨架。咱们逐条验证一下function Foo() {} const foo new Foo(); // 第一句实例走向构造函数的原型 console.log(foo.__proto__ Foo.prototype); // true // 第二句原型对象里有个 constructor 指回构造函数 console.log(Foo.prototype.constructor Foo); // true // 第三句构造函数函数对象的 __proto__ 指向 Function.prototype console.log(Foo.__proto__ Function.prototype); // true // 第四句Function.prototype 的 __proto__ 指向 Object.prototype console.log(Function.prototype.__proto__ Object.prototype); // true这四句话里最难理解的是第三句。它的含义是Foo虽然是你自定义的构造函数但它本身也是被Function这个内置构造函数“造”出来的所以它的__proto__指向Function.prototype。同样的道理Object本身也是一个函数所以Object.__proto__ Function.prototype也是 true。甚至Function.__proto__ Function.prototype也是 true。3.2 对象的原型链终点为什么是 null接着上一节很多读者会问为什么Object.prototype.__proto__是null而不是别的从设计哲学上讲null就代表“这里没有了”。原型链是一个有限长度的链条必须有一个明确的“尽头”否则查找方法的时候会陷入无限的循环。Object.prototype是普通对象的“老祖宗”它再往上的父辈已经没有实际意义了所以语言标准规定它的__proto__必须为null。你试一下运行const obj {}; console.log(obj.__proto__ Object.prototype); // true console.log(Object.getPrototypeOf(Object.prototype)); // null在绝大多数日常业务代码中普通对象的原型链最多也就是obj → Object.prototype → null这么短。但由类实例化出来的对象链条会长一些比如class Animal {} class Dog extends Animal {} const dog new Dog(); // dog - Dog.prototype - Animal.prototype - Object.prototype - null console.log(dog.__proto__ Dog.prototype); console.log(Dog.prototype.__proto__ Animal.prototype); console.log(Animal.prototype.__proto__ Object.prototype); console.log(Object.prototype.__proto__ null);你可以把这个链条想象成一条从具体到抽象的线索最具体的狗依次到狗这个类、动物这个类、再到所有对象的根基Object.prototype最后到 null 完结。这种链式结构正是 JavaScript 实现继承与共享的核心机制。从事后来看正确理解这条链对日常工作有什么实实在在的好处我举一个最常见的例子当你使用某个第三方库的对象时想给它额外扩展一个方法你会写obj.customMethod function(){}。如果只对某一个实例操作那没问题但如果希望所有同类对象都拥有这个方法就应该把它加到该对象所属类的prototype上而不是每个实例单独加。理解原型链你才知道哪些方法应该加在哪儿。3.3 手写 instanceof从根部理解判定规则instanceof也是面试和开发中的高频操作符它判断的是“实例的原型链上是否存在某个构造函数的prototype对象”。很多文章只告诉你怎么用却没有深入讲它的判定逻辑。其实手写一个简易版非常容易而且能顺便加深你对原型链的认识function myInstanceof(instance, constructor) { // 基本类型直接返回 false if (typeof instance ! object typeof instance ! function) { return false; } let proto Object.getPrototypeOf(instance); const prototypeObj constructor.prototype; while (proto ! null) { if (proto prototypeObj) { return true; } proto Object.getPrototypeOf(proto); } return false; } const arr []; console.log(myInstanceof(arr, Array)); // true console.log(myInstanceof(arr, Object)); // true console.log(myInstanceof([], String)); // false这段代码的逻辑非常直白从实例的__proto__出发一路用Object.getPrototypeOf往上爬每爬一层就对比一次直到找到跟构造函数的prototype相等的对象或者爬到null而失败。这里有一个实际开发中容易踩到的坑如果你自己改写了某个对象的__proto__指向instanceof的结果也会随之变化。极端情况下有人为了某种 hack 把对象的__proto__改成了null那它跟任何类都不再存在instanceof关系。这种操作非常危险极容易导致代码行为不可预期。4. 创建对象时到底发生了什么new 操作符与 constructor 背后的真实逻辑4.1 在做项目之前你需要真正理解 new 的四个步骤很多开发者每天都在写new但你要问他在new背后 JavaScript 干了什么事他一般会沉默。其实new的原生执行过程可以拆成四步创建一个全新的空对象。将这个新对象的__proto__指向构造函数的prototype对象。调用构造函数并将构造函数的this绑定到这个新对象上执行函数体代码比如给 this 挂属性。如果构造函数默认返回了一个对象那就用这个对象否则返回新创建的对象。注意第四步有个微妙之处如果构造函数内部显式return了一个普通对象那么new的结果会变成你return的那个对象而不是新创建的对象。但如果你 return 的是一个基本类型比如数字、字符串则会被忽略仍然返回新对象。来看一个经典案例function Person(name) { this.name name; return { nickName: 化名 }; } const p new Person(小明); console.log(p.name); // undefined console.log(p.nickName); // 化名构造函数返回了对象字面量new 出来的人就没有 name 属性。这在真实项目中并不常见但假如你去读某些封装库源码可能会看到利用这个特性做“工厂模式”的写法。为了加深理解我手写一个简易版myNew你可以在本地运行对比效果function myNew(constructor, ...args) { // 第一步创建一个空对象并把原型指向 constructor.prototype const obj Object.create(constructor.prototype); // 第三步以 obj 为 this 执行构造函数 const result constructor.apply(obj, args); // 第四步如果构造函数返回是对象则返回这个对象否则返回 obj return result (typeof result object || typeof result function) ? result : obj; } function Animal(name) { this.name name; } Animal.prototype.speak function () { console.log(${this.name} 在叫); }; const dog myNew(Animal, 旺财); console.log(dog.name); // 旺财 dog.speak(); // 旺财 在叫 console.log(dog instanceof Animal); // true通过手写 new你能更清楚地知道实例身上为什么会有构造函数的属性因为执行了原型上的方法绑定过程也更能理解为什么说“构造函数中的 this 就是未来的实例对象”。4.2 一个面试题引发的思考constructor 到底可不可靠关于constructor属性有一个高频面试题function A() {} const a new A(); console.log(a.constructor A); // true console.log(a.constructor A.prototype.constructor); // true这个结果成立是因为a自身没有constructor属性于是沿原型链找到A.prototype.constructor它指向 A。看起来一切正常。但假如你在代码里不小心改写了A.prototype呢function A() {} A.prototype { custom: true }; const a new A(); console.log(a.constructor A); // false console.log(a.constructor); // Object看到了吗当你整体替换A.prototype时新的原型对象上默认没有constructor属性此时a.constructor会顺着链条继续往上找到Object.prototype.constructor也就是Object。这就是一个典型的“constructor 不可靠”场景。正确的做法是每次整体替换prototype之后手动补回constructor指向保持关系链不破function A() {} A.prototype { custom: true }; A.prototype.constructor A; const a new A(); console.log(a.constructor A); // true老实说这个点在实际业务开发中极少触发但踩过坑的人都知道当你在做组件二次封装或写底层库时原型链的完整性极其重要。破坏一个 constructor 指向可能导致很多依赖instanceof或constructor的类型判断代码静默失败且特别难追踪定位。5. 继承如何把“家族财产”优雅地传承下去5.1 别再用组合继承的“错误姿势”了JavaScript 的继承有很多种写法但万变不离其宗——本质上都是在操纵“原型链的指向”。我们先把最经典、早期教科书中常见的“组合继承”拿出来看function Parent(name) { this.name name; this.hobbies [看书, 运动]; } Parent.prototype.sayName function () { console.log(this.name); }; function Child(name, age) { Parent.call(this, name); // 第一次继承父类实例属性 this.age age; } Child.prototype new Parent(); // 第二次继承父类原型方法 Child.prototype.constructor Child; const kid1 new Child(小明, 8); const kid2 new Child(小红, 10); kid1.hobbies.push(画画); console.log(kid1.hobbies); // [看书, 运动, 画画] console.log(kid2.hobbies); // [看书, 运动]两个实例互不影响组合继承确实是可用的但它有一个被反复诟病的问题Parent被调用了两次。第一次是在Child内部通过Parent.call(this, name)把父类实例属性复制到子类实例上第二次是在Child.prototype new Parent()创建原型对象时又让 Parent 的构造函数执行了一遍于是Child.prototype上多出一份没用的 name 和 hobbies 属性。这份属性既不会被子类实例使用因为实例自己已经有了又白白占着内存。5.2 寄生组合式继承面试与实战的“标准答案”后来业界渐渐统一推荐使用“寄生组合式继承”核心思路是利用一个空函数做桥梁让子类原型直接连接到父类原型而不是通过执行父类构造函数来生成子类原型。经典写法如下function inheritPrototype(Child, Parent) { const prototype Object.create(Parent.prototype); prototype.constructor Child; Child.prototype prototype; } function Parent(name) { this.name name; } Parent.prototype.sayName function () { console.log(this.name); }; function Child(name, age) { Parent.call(this, name); this.age age; } inheritPrototype(Child, Parent); Child.prototype.sayAge function () { console.log(this.age); }; const child new Child(小明, 8); console.log(child instanceof Parent); // true console.log(child instanceof Child); // true child.sayName(); // 小明 child.sayAge(); // 8这段代码的关键在于Object.create(Parent.prototype)它会返回一个新对象该新对象的__proto__指向Parent.prototype。然后我们把这个新对象指派给Child.prototype并补回constructor指向Child。这种方案的巧妙之处在于不会执行父类构造函数只在原型层面建立父子链接。父类实例属性通过Parent.call一次性复制到子类实例上原型上的公共方法则通过链式共享。这就是“寄生组合式继承”被公认为最佳组合继承方案的原因。你会注意到上面这段代码其实就是一个简化版 ES6class继承的底层原理。当你编写class Child extends Parent {}时JavaScript 引擎做的事情与寄生组合式继承的思路几乎一致。5.3 class 继承的真身extends 背后的原型链操作很多新人不理解为什么 class 继承看起来跟函数构造继承差别很大其实底层完全一样class 只是语法糖。看下面这个例子class Animal { constructor(name) { this.name name; } eat() { console.log(${this.name} 在吃饭); } } class Dog extends Animal { constructor(name, breed) { super(name); this.breed breed; } bark() { console.log(${this.name} 在汪汪叫); } } const dog new Dog(旺财, 金毛); dog.eat(); // 旺财 在吃饭 dog.bark(); // 旺财 在汪汪叫 console.log(dog instanceof Dog); // true console.log(dog instanceof Animal); // true console.log(Dog.prototype.__proto__ Animal.prototype); // true关键就是最后一行Dog.prototype.__proto__ Animal.prototype。这意味着 Dog 的实例不仅可以在 Dog.prototype 上找方法还可以顺着链子走到 Animal.prototype 上找方法。所以 Dog 的实例能调用 eat本质上是因为 eat 存在于 Animal.prototype 上而 Dog.prototype 的原型就是 Animal.prototype。super(name)的作用也很有趣它在底层就是类似Animal.call(this, name)的过程不过它还会做一件事——让这个方法调用时的this正确指向当前实例同时保证能够继续访问父类原型上的方法。关于 class 继承有一个经典面试题super是否必须写在 constructor 第一行其实不必“必须第一行”但在 super 调用之前不能访问this。因为引擎需要先调用父类构造函数完成实例属性和 this 的初始化之后才能让子类去添加自己的属性。如果你反过来写就会报 “Must call super constructor in derived class before accessing this or returning from derived constructor” 的错误。5.4 各继承方案对比与选型建议写代码这么多年我的经验是日常业务开发直接使用 ES6 的class语法就够了不要自己手写各种偏门继承组合。但如果你在阅读源码或维护老项目看到经典组合继承、原型链继承这些写法得能一眼看出来它们的问题在哪儿。这里给大家整理一份我在内部培训时常用的对比表继承方案实现要点优点缺点应用建议原型链继承子类原型直接指向父类实例写法简单多个实例共享父类引用类型属性互相污染不推荐单独使用借用构造函数继承在子类中调用父类构造函数实例属性完全隔离不能获取父类原型上的方法极少单独使用组合继承构造函数继承 原型链继承属性隔离且方法共享父类构造函数被调用两次老项目遇到能看懂即可寄生组合式继承用空对象承接父类原型无多余调用性能最佳写法稍复杂适合手写底层类库ES6 class 继承extends super语义清晰官方推荐旧浏览器需转译日常开发首选在选型上我的建议很明确团队新项目一律用 class 继承不要搞“为了炫技而炫技”的继承组合。JavaScript 的继承能力本身不算弱但继承层级过深会导致代码难以理解和维护。很多时候组合优于继承能用函数组合、依赖注入解决的问题不要硬生生搞出五层原型链。6. 快速判断与实用技巧从原型链的角度优化你的日常开发6.1 三种方式检查属性归属in、hasOwnProperty、Object.keys在写代码时我们经常需要判断一个属性是否存在于对象身上。但这个“存在”有两种截然不同的含义一种是指“原型链上能看到”另一种是“对象自己所有”。二者之间的差异用in操作符和hasOwnProperty就能区分。function Person() {} Person.prototype.name 某人; const p new Person(); console.log(name in p); // true因为原型链上有 console.log(p.hasOwnProperty(name)); // false因为不是自己的属性 console.log(Object.keys(p)); // []只列自身可枚举属性再举一个实际项目里的常见场景你要遍历一个从后端拿到的数据对象只想输出对象自己拥有的字段不想输出从Object.prototype继承来的方法。这个时候就应该用hasOwnProperty做一层过滤否则可能不小心把toString、valueOf等原型方法也打印出来。还有一个大家可能没注意到的冷知识Object.keys()只返回自身的可枚举属性而for...in会同时遍历原型链上的可枚举属性。因此在for...in循环内部通常建议配合hasOwnProperty使用避免可继承的可枚举属性干扰业务逻辑。Object.prototype.customTag global; const obj { a: 1 }; for (const key in obj) { console.log(key); // 输出 a也输出 customTag } for (const key in obj) { if (obj.hasOwnProperty(key)) { console.log(key); // 只输出 a } }我见过有人在业务代码里忘了这种区别导致for...in遍历时突然多出来一些莫名其妙的字段最后排查半天才发现是某个工具库动过Object.prototype。所以一个基本的开发素养永远不要在运行时去污染内置原型。6.2 使用 Object.create 实现“干净”的对象和极简原型链控制Object.create是一个极其强大但经常被忽略的方法。它接受两个参数第一个是原型对象第二个是属性描述对象。它可以让你精准控制新对象的__proto__指向非常适合用来实现继承关系、或创建“没有原型”的纯粹字典对象。const base { version: 1.0, getVersion() { return this.version; } }; const child Object.create(base); child.name 子对象; console.log(child.name); // 子对象 console.log(child.getVersion()); // 1.0来自原型链 console.log(Object.getPrototypeOf(child) base); // true再比如创建一个完全空白的对象没有任何原型链干扰const pureObj Object.create(null); console.log(Object.getPrototypeOf(pureObj)); // null console.log(pureObj.toString); // undefined因为没有任何原型方法这种pureObj特别适合用作 Map 出现之前的“纯字典结构”你不用担心它的 key 会不会跟原型上的方法名冲突。比如你想存一个{ toString: 自定义 }在普通对象上会导致原型方法被遮蔽但用Object.create(null)就不会有任何问题。不过要注意纯空对象无法调用hasOwnProperty、toString等方法若需要检测属性得借助Object.prototype.hasOwnProperty.call(pureObj, key)这种方式。另外Object.create(null)在很多框架源码里常被用来创建所谓“守卫对象”可以避免原型链干扰。这个技巧虽然小众一旦用对地方效果奇佳。6.3 开发中的避坑指南黑魔法尽量不要碰最后必须严肃地聊一聊“修改原型链”这类黑魔法的边界。虽然 JavaScript 允许你直接改写任意对象的__proto__也可以给Array.prototype挂挂载方法但我个人强烈不建议在业务代码中这么干。原因有三点一是性能开销。现代 JavaScript 引擎对对象属性访问做了大量优化前提是对象结构稳定。如果你频繁改变__proto__引擎无法做内联缓存访问属性的性能会显著下降。在某些性能敏感的页面里这种改动可能带来肉眼可见的卡顿。二是可维护性灾难。一旦你改了内置原型团队所有人都受影响。别人写for...in时可能突然多出你挂的方法别人使用Array.map时可能触发你重写过的版本而这些“隐性行为”在代码评审里极难被察觉。三是规范化趋势。ECMAScript 标准对新语法和内置对象的改动已经越来越克制官方也不建议开发者自行扩展全局对象。像Array.prototype.flat、Object.hasOwn这类新特性都是语言规范亲自实现而不是鼓励大家自己往原型上添加。话说回来理解__proto__的作用仍然很有必要尤其是调试环节。比如你用console.dir打印一个复杂对象时Chrome DevTools 会展示出__proto__链条你能一眼看出这个对象从哪个类来、继承了哪些属性和方法。这种排查问题的方式比单纯看报错信息更高效。写到这里我不禁回想起自己刚学 JavaScript 时完全被原型链绕进去的那段日子。有一次在项目里排查 bug发现某个组件拿到的数据对象多了一个方法怎么都找不到是谁加上的。后来用console.dir一层层展开__proto__才发现是某段公共代码往Object.prototype上挂了一个全局方法问题瞬间清楚了。从此以后我对原型链的态度是理解它、敬畏它、不乱动它。希望这篇“家族关系大揭秘”能让你看清楚原型链的本质它不仅是 JavaScript 实现复用的核心机制更是理解继承、new、instanceof、class的一把万能钥匙。把这条链子理顺了再看任何框架的源码你都会有底气得多的底气。
