JavaScript面向对象原理：原型链与Class语法底层对比

JavaScript 的面向对象体系在底层本质上始终是基于原型链（Prototype Chain）的委托机制，ES6 引入的 class 语法并没有在 V8 等引擎层面引入全新的传统面向对象内存模型。然而，将 class 仅仅理解为“写起来更舒服的语法糖”是不够准确的：Class 语法规范在引擎级别加入了必须通过 new 调用、方法默认不可枚举、强制严格模式，以及基于内部槽位 [[HomeObject]] 实现 super 静态绑定等安全约束与行为修正。本文将从底层内存结构出发，拆解原型链运作过程、ES5经典继承演化，并与 ES6 Class 展开细致的底层机制对比。

一、原型体系的底层骨架：构造函数、prototype 与 __proto__

在深入对比语法之前，必须先理清 JavaScript 运行时的对象关联关系。与 Java、C++ 等基于“类与副本实例化”的语言不同，JavaScript 对象是通过内部指针连接在一起的活引用。任何普通函数在声明时，JavaScript 引擎都会为其自动创建并挂载一个 prototype 对象，该对象默认包含一个指向原函数的 constructor 属性。

当通过 new Person('Alice') 创建实例时，引擎内部会执行以下核心操作：

1. 在内存中开辟一个新的普通对象。
2. 将新对象的内部隐藏指针 [[Prototype]]（在浏览器等环境中通常通过 __proto__ 暴露，规范推荐使用 Object.getPrototypeOf() 访问）指向构造函数的 Person.prototype。
3. 将构造函数内的 this 绑定到这个新建的对象，并执行构造函数的执行体。
4. 如果构造函数没有显式返回非原始对象，则默认返回该新创建的对象。

当访问 p1.sayHello() 时，引擎首先在实例 p1 本身的对象自身属性（Own Properties）中检索；若未找到，便沿着其隐式原型 __proto__ 前往 Person.prototype 查找；若依然不存在，继续沿原型的 __proto__ 向上追溯至 Object.prototype，直到顶层的 null。如果整条链遍历完毕仍未命中，则返回 undefined（若尝试将其作为函数调用则抛出 TypeError）。

二、ES5 面向对象继承的探索与演进路径

在 ES6 出现之前，前端开发者为了实现类似传统面向对象的“类继承”，经历了一套漫长的设计模式演化。理解这些方案各自的缺陷，是理解 Class 语法设计初衷的前提。

1. 原型链继承的致命缺陷

最简单的尝试是直接让子构造函数的原型指向父构造函数的实例：Child.prototype = new Parent()。这种方式最大的问题在于：父类实例上的所有属性都会变成子类所有实例共享的原型属性。一旦父类包含数组、对象等引用类型数据，一个子类实例的修改会直接污染所有其他子类实例。

2. 借用构造函数（构造函数伪造）

为了解决引用数据共享的问题，开发者提出了在子构造函数中执行父构造函数：

function Child(name, age) {
  Parent.call(this, name); // 借用父类构造函数
  this.age = age;
}

该方案虽然隔离了实例属性，但父类原型上定义的方法（Parent.prototype）完全无法被子类复用，所有方法只能写在构造函数内每次重复创建，造成严重的内存损耗。

3. 组合继承与寄生组合式继承

将上述二者结合后产生了组合继承，但它在实例化时会执行两次父类构造函数（一次在 Child.prototype = new Parent()，一次在 Child 内部的 Parent.call(this)），导致子类原型上残留无用的重复字段。

最终成熟的标准解法是寄生组合式继承（Parasitic Combination Inheritance）。它通过 Object.create(Parent.prototype) 创建一个空中间对象作为桥梁，既切断了父类实例属性的重复调用，又完美保留了原型链层级：

function Parent(name) {
  this.name = name;
  this.colors = ['red', 'blue'];
}
Parent.prototype.sayName = function() {
  return this.name;
};

function Child(name, score) {
  Parent.call(this, name); // 核心 1：借用构造函数继承属性
  this.score = score;
}

// 核心 2：寄生式继承父类原型方法，切断多余实例化
Child.prototype = Object.create(Parent.prototype);
Child.prototype.constructor = Child; // 修复被覆盖的 constructor 指针

三、ES6 Class 的底层解构：不仅是语法糖

很多开发者认为 class 完全等同于寄生组合式继承的缩写。但如果我们将一段典型的 ES6 Class 代码在 Babel 中转译为 ES5，或者直接在 JavaScript 虚拟机源码层面观察，会发现 Class 带来了几项具有约束力的底层差异：

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
  toString() {
    return `(${this.x}, ${this.y})`;
  }
  static origin() {
    return new Point(0, 0);
  }
}

1. 方法默认不可枚举（Non-enumerable）

在 ES5 中，如果我们通过 Point.prototype.toString = function() {} 挂载方法，该属性的描述符中 enumerable 默认为 true。这意味着在 for...in 循环或者 Object.keys() 检查时，该原型方法会被枚举出来。

而在 ES6 Class 中，类内部定义的所有普通原型方法与静态方法，其属性描述符的 enumerable 均强制为 false。引擎在底层执行类似于 Object.defineProperty(Point.prototype, 'toString', { enumerable: false, ... }) 的配置，避免了原型方法在日常迭代中意外泄露。

2. 强制使用 new 调用与内部严格模式

ES5 的构造函数本质上只是一个包含 [[Call]] 和 [[Construct]] 内部方法的普通函数，如果开发者忘记写 new 直接执行 Point(1, 2)，代码不会报错，而是把属性直接挂载到全局对象（如 window 或 global）上，引发严重 Bug。

Class 在引擎底层被标记为必须通过 [[Construct]] 执行。如果不带 new 直接调用 Class，V8 引擎会直接抛出原生运行时异常：TypeError: Class constructor Point cannot be invoked without 'new'。此外，Class 作用域内部默认开启严格模式（Strict Mode），无需手动书写 'use strict'。

3. 双向继承：原型链与静态属性继承

在 ES5 的常规继承中，我们通常只处理了实例原型的继承：Child.prototype.__proto__ === Parent.prototype。但父类的静态方法（挂载在 Parent 本身的属性）并不会自动被 Child 继承，必须手动执行 Object.setPrototypeOf(Child, Parent)。

而 ES6 Class 的 extends 关键字在底层直接完成了两条原型链的链接：

• 实例方法链：SubClass.prototype.__proto__ === SuperClass.prototype（继承父类原型方法）
• 静态方法链：SubClass.__proto__ === SuperClass（继承父类静态方法和属性）

四、实例化时序与 super 底层绑定机制

除了静态方法继承与描述符限制外，ES5 继承与 ES6 Class 之间最深刻的底层机制差别，在于实例对象的构建时机以及 super 关键字的寻址方式。

1. 实例化创建顺序：“先子后父” vs “先父后子”

在 ES5 的经典寄生组合式继承中，实例化时是由子类构造函数首先创建出自身的实例对象 this（由 new Child() 隐式分配内存），随后在代码体内通过 Parent.call(this, ...)，将这个已经存在的 this 当作上下文传入父类构造函数中进行修饰。

而在 ES6 Class 规范中，实例化的顺序被彻底颠覆为“先父后子”：

• 子类的构造函数中没有默认的初始 this 对象。
• 子类必须首先调用 super()。super() 的本质是调用父类构造函数，由父类完成最初的实例化内存分配（初始化内部插槽）。
• 父类构造函数将构建完成的实例返回给子类后，子类才真正拥有合法的 this 绑定，随后才允许在子类中通过 this.xxx = yyy 进行自定义修饰。

2. 为什么原生内置对象（Array、Error）在 ES5 中无法真正继承？

这一实例化顺序的差异，直接解开了一个困扰前端开发者多年的历史难题：为什么 ES5 无论怎么写都无法完美继承内置对象（例如继承 Array 打造子类）？

在 ES5 中，Array.call(this) 忽略了传入的 this，或者无法将原生数组特有的底层内部槽（如 [[ArrayData]] 以及动态更新 length 的核心机制）正确安装到子类的普通对象上。而在 ES6 中，由于是父类（Array）先通过 super() 创建具有原生槽位的实例再传递给子类，使得 class MyArray extends Array 能够完美继承 length 的自动同步和索引行为。

3. super 的静态绑定机制：[[HomeObject]]

在普通函数中，this 是动态绑定的，取决于函数运行时由谁调用。但 super 是静态绑定的。

当在 Class 内部定义包含 super.someMethod() 的简写方法时，JavaScript 引擎在编译该方法时会为其隐式添加一个内部槽位：[[HomeObject]]，该槽位永远固定指向声明该方法的 Class 原型对象（即 SubClass.prototype）。

当执行到 super.someMethod() 时，引擎内部的查找逻辑是严格确定的：

// 引擎底层伪代码逻辑
const proto = Object.getPrototypeOf(method.[[HomeObject]]);
return proto.someMethod.call(this);

正因为 [[HomeObject]] 在方法创建时就已经静态固化，即便这个方法被赋值给其他对象、作为回调函数脱离上下文传递，只要它内部使用了 super，它所追溯的父级原型始终准确无误。

五、原型链与 Class 核心特性对照总结

为了帮助读者建立清晰直观的认识，下表系统梳理了 ES5 原型模式与 ES6 Class 语法在语法层、引擎层与运行时的全部核心区别：

对比维度	ES5 原型模式（寄生组合继承）	ES6 Class 语法体系
本质与基石	原型链（Prototype Chain）与原型委托	基于原型机制的语法包装与安全强化规范
调用限制	允许直接当作普通函数调用（Person()）	必须使用 new 调用，否则抛出 TypeError
方法可枚举性	挂载在 prototype 上的方法默认 enumerable: true	定义在 class 体内的方法默认 enumerable: false
变量提升 (Hoisting)	function 声明整体提升，可先调用后声明	存在暂存死区（TDZ），在声明语句前不可使用
静态成员继承	需手动执行 Object.setPrototypeOf(Child, Parent)	由 extends 自动构建 Child.__proto__ === Parent
实例化构建顺序	先子后父（先创建子实例，再借调父构造函数）	先父后子（父类先构建实例并返回，子类再挂载）
内置类继承支持	无法真正继承 Array、Error、RegExp 等底层特性	完美继承原生对象内部插槽与行为
super 寻址	需手动书写 Parent.prototype.fn.call(this)	基于 [[HomeObject]] 内部槽位静态定位父原型

六、实践总结与工程建议

在日常现代工程开发中，应始终优先使用 class 语法编写面向对象逻辑。这不仅是因为语法更精炼可读，更重要的是 Class 由 JavaScript 引擎在底层做了大量防呆优化（避免遗漏 new 污染全局、杜绝方法枚举副作用、支持静态方法继承等），能够让团队代码具备更高的鲁棒性与工程一致性。

与此同时，理解底层的原型链机制依然不可或缺。无论是分析前端性能排查内存泄露、阅读复杂开源框架的底层黑魔法（如 Vue/MobX 的响应式原型劫持、Node.js 核心事件模块继承），还是在性能敏感场景下规避长原型链造成的属性查找开销，深刻理解“Class 形式、原型本质”都是写出高质量 JavaScript 代码的关键基石。