JavaScript原型链继承本质：__proto__与class语法糖的底层区别

在 JavaScript 中，class 关键字常被称为原型继承的“语法糖”。很多开发者因此误认为 class 只是将 prototype 相关的赋值语句换了层马甲。然而从 JavaScript 引擎底层的规范实现来看，两者存在若干根本性的行为割裂：class 不仅强制锁定不可枚举性、限制必须通过 new 触发构造器内部槽位 [[Construct]]，更在静态继承链关联、以及 super() 执行引发的实例生成顺序上，彻底重构了原型链装配的时序机制。

一、原型继承基石：__proto__、prototype 与链式查找

理解任何继承方式的前提，是厘清隐式原型链属性检索模型。在 ECMAScript 规范中，每一个普通对象内部都包含一个隐式引用槽位 [[Prototype]]，在浏览器宿主环境中通常通过访问器属性 __proto__ 暴露出来；而只有函数对象才默认具备显式属性 prototype。

当尝试访问对象 obj.property 时，引擎内部的查找算法极为纯粹：首先检查 obj 本身的自有属性集合（Own Properties）。若未命中，则沿着 obj.__proto__ 指向的原型对象继续回溯，层层递进，直至最终访问到 Object.prototype.__proto__（其值为 null）。如果在整条链路上均未检索到目标属性，则返回 undefined。

二、传统原型继承的演进推导与 __proto__ 陷阱

在 ES6 出现前，实现子类继承父类的最经典方案是“寄生组合式继承”。开发者必须手动执行多个维度的组装：在子类构造函数中借用父类构造函数以获取自有属性，再通过 Object.create 构造空的原型中间对象，最后手动补回 constructor 属性。

以下是寄生组合继承的标准范例：

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

Parent.prototype.sayName = function() {
  return this.name;
};

function Child(name, age) {
  // 1. 借用构造函数：初始化实例自有属性
  Parent.call(this, name);
  this.age = age;
}

// 2. 切断直接引用，构建纯净的中间原型对象
Child.prototype = Object.create(Parent.prototype);

// 3. 必须手动修复丢失的 constructor 指向
Child.prototype.constructor = Child;

Child.prototype.sayAge = function() {
  return this.age;
};

三、ES6 class 语法糖的深层解构：它不只是语法包装

ES6 引入了 class 与 extends 关键字，书写形式更加贴近强类型面向对象语言：

class Parent {
  constructor(name) {
    this.name = name;
  }
  static getSpecies() {
    return 'Homo sapiens';
  }
  sayName() {
    return this.name;
  }
}

class Child extends Parent {
  constructor(name, age) {
    super(name);
    this.age = age;
  }
  sayAge() {
    return this.age;
  }
}

表面上看，这只是将 Child.prototype = Object.create(Parent.prototype) 隐藏了起来，但深入到引擎字节码和 ECMAScript 规范层，class 强制设定了如下关键底层约束：

1. 属性描述符：方法完全不可枚举

在普通函数原型模式下，直接在 Child.prototype 上赋值的方法默认是可枚举的（enumerable: true）。当使用者通过 for...in 循环遍历实例属性时，所有原型方法都会被莫名迭代出来。而 class 体内声明的所有方法，底层都会被 Object.defineProperty 强制锁定为 enumerable: false，避免了原型污染。

2. 调用守卫：[[IsClassConstructor]] 内部槽

传统的构造函数 function Person() {} 本质上就是普通函数，如果不加防御代码，开发者完全可以通过 Person() 直接裸调，导致 this 绑定到全局对象或 undefined。但 ES6 的 class 在生成构造器函数时，其内部槽位会被打上 [[IsClassConstructor]]: true 标记。一旦作为普通函数调用（缺少 [[Construct]] 入口），引擎将无条件抛出 TypeError: Class constructor cannot be invoked without 'new'。

3. 静态继承：构造函数自身的双重原型链

在传统寄生组合继承中，开发者只完成了 Child.prototype.__proto__ === Parent.prototype 的关联。这就导致挂载在 Parent.getSpecies 上的静态方法，子类 Child.getSpecies 根本无法直接访问！必须额外显式写上一句：

Object.setPrototypeOf(Child, Parent);

而在 ES6 的 extends 语义中，引擎会在底层自动完成两条并行的原型链绑定：一条是实例原型链（原型对象之间），另一条是静态原型链（构造函数自身之间）。

四、实例创建顺序的本质分水岭：super() 与 this 的诞生

在所有底层区别中，最具决定性的分水岭是实例 this 对象的构建时序与主体。正是这一机制，决定了为什么传统 ES5 原型继承无法原生扩展内置类（如 Array 或 Error），而 ES6 class 可以。

1. 传统继承：子类先造 this，再借父类装饰

在 ES5 中，执行 new Child() 的第一步，是引擎由 Child 构造函数分配一块内存创建新对象：this = Object.create(Child.prototype)。紧接着在子类代码中显式调用 Parent.call(this)，本质只是借用父类函数去往子类已经创建好的 this 上挂载属性。

由于这个 this 是子类先行创建的，像 Array 这样依赖引擎内部槽位 [[ArrayData]] 的原生对象，根本无法通过 Array.call(this) 将底层槽位附加给子类新对象，导致 SubArray.length 自动维护机制彻底失效。

2. class 继承：父类先造 this，子类 super() 接收装饰

ES6 派生类的 constructor 内部槽为 [[ConstructorKind]]: "derived"。进入构造函数时，子类的 this 处于完全未初始化（Uninitialized）的状态。如果在调用 super() 之前访问 this，引擎会直接抛出 ReferenceError: Must call super constructor in derived class before accessing 'this'。

当执行 super(...args) 时，子类实际上将构造请求代理给了父类的 [[Construct]] 内部方法，同时附带了 new.target = Child。因此，实际的物理实例内存是由最顶层的父类基类构造函数负责分配创建的，随后该实例层层返回至派生类的 constructor 作用域中，最后才允许子类对这个实例进行个性化装饰。

class Base {
  constructor() {
    // 此时由父类创建实例，且 new.target 指向 Derived
    console.log('Base init, new.target === Derived:', new.target === Derived);
  }
}

class Derived extends Base {
  constructor() {
    // console.log(this); // 报错！ReferenceError: Must call super constructor
    super();              // 父类分配实例并传递给子类
    console.log(this);    // 成功！此时 this 已获得内存实例引用
    this.customProp = 42;
  }
}

五、全维度对比与技术选型建议

为了让不同阶段的技术差异一目了然，下表列出了从直接操作 __proto__、传统寄生组合继承到现代 class 的全方位特征对比：

六、结语与工程实践要点

综上所述，ES6 的 class 绝不仅仅是简写版语法糖。尽管它最终依然基于 JavaScript 的 [[Prototype]] 链条来实现属性回溯，但它通过严苛的词法调用保护、不可枚举的方法描述符、双重静态原型继承以及由父类优先构建 this 内存对象的规范机制，从根本上弥补了以往直接操作 prototype 或 __proto__ 的脆弱性与性能黑洞。

在日常工程实践中：

• 全面优先使用 class 与 extends 组织业务层面向对象代码，利用引擎对静态结构的极致优化。
• 严格避免在运行时直接读取或修改 __proto__；若确实存在动态关联原型的元编程需求，优先使用 Object.create(proto) 初始化对象，而非在中途更改既有对象的原型链。
• 在排查复杂继承关系时，区分好“实例方法链路”（instance.__proto__）与“静态方法链路”（Constructor.__proto__），即可快速定位静态属性无法访问或原型断裂问题。