面试官端着一杯水问出那句“讲讲ES6的继承”时，很多候选人心里是窃喜的——class extends背得滚瓜烂熟，super()也写了无数次，这题不是送分吗？但实际面下来，十个里有七个倒在了追问环节：super到底指向什么？子类构造函数不写super会不会报错？继承Array为什么length属性会诡异？这一问就露馅了。
ES6继承从来不是“会写class A extends B”这么简单。它背后是原型链、构造器调用顺序、静态属性继承、内置类型子类化这些机制在托底。这篇文章就把ES6继承从头到尾拆开，从语法骨架到运行原理，再到面试官常设的追问陷阱，一个个梳理清楚。无论是准备跳槽的前端，还是想真正把class用明白的开发者，这篇文章都能让你在“继承”这道题上答出深度。
1. 面试官为什么揪着继承问：这题背后的原型链考点
1.1 从原型式继承到class的演进，不是语法糖那么简单
很多人把ES6的class理解成“ES5原型继承的语法糖”，这个说法只对了一半。语法层面确实是更友好的封装，但class带来的是一整套更严格的继承语义，包括静态字段继承、访问器属性和不可枚举的方法定义方式。这些在ES5里都没有原生支持。
ES5时代写一个“类”，本质是构造函数加原型方法：
function Animal(name) { this.name = name; } Animal.prototype.say = function() { console.log(this.name + '在叫'); };继承就要手动连原型链。经典的组合继承是先借用父类构造器初始化实例属性，再把子类原型指向父类原型的副本：
function Dog(name) { Animal.call(this, name); } Dog.prototype = Object.create(Animal.prototype); Dog.prototype.constructor = Dog;这套手动操作看似简单，但有个隐蔽问题：Object.create斩断了子类原型对父类原型的直接引用，构造器指针还需要手动纠正。代码写得多了总会漏掉某一行，一旦漏掉，instanceof、constructor判断就会出现诡异行为。ES6 class把这些步骤规范化了，extends一写，JS引擎内部帮你处理原型链挂接。这也是面试题存在的根本意义：考察你有没有理解JS对象模型。
1.2 面试者最常犯的认知偏差：以为继承只是“属性拿过来”
我见过不少候选人能咕噜咕噜背出class extends的写法，但一问“子类实例的原型链有几层”，就愣了。真正的理解要从原型链视角去看待class继承。
比如：
class Parent {} class Child extends Parent {} let c = new Child();这个c身上挂着链子：
- c的原型是Child.prototype
- Child.prototype的原型是Parent.prototype
- Parent.prototype的原型是Object.prototype
这不是我背出来的记忆，而是JS继承机制的内在结构。面试官问“ES6继承方法”，本质上就在问你有没有看清这条链。链子理清了，后续的super调用、方法查找、instanceof结果就都有了根。
这也就解释了为什么很多人在“自定义React组件类继承组件基类”时能正常工作，但一套用到普通工具类上就出问题——因为他们没有意识到class继承的方法查找依赖原型链逐级向上，而不仅仅是被extends“复制”到子类上。
2. extends的骨架：super、构造器与静态成员的继承逻辑
2.1 构造函数里那行super()为什么必须最先出现
代码里最常见的报错长这样：
class Child extends Parent { constructor(name) { this.name = name; // ReferenceError: Must call super constructor in derived class super(name); } }这个错被问过太多次。深层次原因要从new的工作方式说起。
普通类实例化的流程是：引擎创建一个新对象，这个对象的原型指向构造器的prototype，然后以这个新对象为this执行构造器函数体。派生类的构造器有一点根本性不同——它的this不是凭空创建的，而是由父类构造器负责创建。子类构造器里的this一直处于未初始化状态，直到调用super()后，父类构造器完成了第一步初始化，this才真正“活”过来。
所以子类构造器里，super()之前访问this或返回一个对象，都会触发运行时错误。只要想用this，就必须先完成super调用。这是所有extends继承的子类构造器不可违背的规则。有些偏门的写法——比如构造器里不写constructor方法——反而可以不用管super，因为引擎会给出默认的：
class Child extends Parent {} // 等价于： class Child extends Parent { constructor(...args) { super(...args); } }这个默认行为也解释了为什么“继承的类不写constructor”绝大多数情况下是安全的。真实项目中也确实有这个规律：显式定义constructor又有初始化逻辑时，就退无可退，必须先super()。
2.2 方法、静态方法、getter/setter在继承里的行为差异
class声明的方法默认不可枚举，这与ES5手动赋值到prototype上的方法可枚举不一样。继承过程中，方法不是复制到子类的，而是通过原型链供子类实例查找调用。这意味着父类原型方法后期做出修改，子类实例也能看到修改，这与直接拷贝的继承模型有本质区别。
静态方法一样能通过extends继承。静态方法挂在构造器本身的属性上，子类构造器通过原型链也可以访问到父类静态方法：
class Parent { static ping() { return 'pong'; } } class Child extends Parent {} Child.ping(); // 'pong'这一点很容易被忽略，但实际业务里的静态工厂方法、静态配置读取经常用到这个特性。顺便说一句：类内部定义的getter/setter也会挂到原型上，继承时自然可用。这也是面试时能多讲一句的加分细节——因为很多只学过ES5的开发者，会把访问器属性挂到实例上，而class语法让它们可以被原型化继承。
2.3 继承关系下new到底做了什么
被new调用时，除了构造器自身执行，派生类还有一些特殊处理：
- 先收集构造器参数，传给默认或自定义构造函数
- 执行super()前this不可用，这是雷区
- super()返回的如果是对象，会作为this使用；如果是基本类型或null，则忽略它，继续用原本创建好的this
这些处理比较底层，但搞懂了就明白为什么子类构造器可以完全重写实例的构建过程。我在面试中常提醒候选人：理解这个顺序后，你甚至可以“在super()前后拦截父类构造逻辑”，从而设计出工厂化的父子类架构，面试官也会因此高看你一眼。
3. 和ES5那套寄生组合继承对比：class到底改进了什么
3.1 ES5手工搭原型链的完整代码
目前主流环境下ES5写法依然大量存在，尤其是老项目维护场景。要对比出class的改进，先得把ES5最佳实践——“寄生组合式继承”——完整写出来看：
function Parent(name) { this.name = name; } Parent.prototype.say = function() { console.log('我是' + this.name); }; function Child(name, age) { Parent.call(this, name); this.age = age; } // 关键：以父类原型为模板创建新对象，而不是直接赋值为父类原型 Child.prototype = Object.create(Parent.prototype); Child.prototype.constructor = Child; // 子类扩展方法 Child.prototype.introduce = function() { console.log(this.name + '，' + this.age + '岁'); };再举一个用constructor继承静态属性的补丁写法：
Object.setPrototypeOf(Child, Parent);如果不做这一步，子类构造器拿不到父类的静态方法。ES5里静态继承最容易漏，很多老代码根本没有这一层处理。ES6 class extends则自动完成这部分。
3.2 class对比后的三个关键差异
差异一是原型链挂接的正确性被内置保证。手工写法里忘了用Object.create而直接赋值为父类prototype是致命错误——会导致子类实例“变成”父类实例，instanceof彻底错乱。class语法从根本上杜绝了这种低级失误。
差异二是构造器借用机制被标准化。ES5借用父类构造器是调用Parent.call(this, ...)，本质上只是借用函数，不触发new流程。class的super()则是引擎层面的派生构造器协作：父类构造器成了真正意义上的“父类构造流程”，而不是被普通函数调用走个过场。
差异三是静态继承被原生支持。ES5里想继承父类静态属性需要Object.setPrototypeOf手动接线，或者遍历父类属性再拷贝到子类上。class的static关键字和extends天然结合，Child.ping()这种访问变得顺理成章。
这三个差异恰好对应面试官想听的三层理解：原型链、构造器协作、静态成员。能把它们对照讲清楚，比单纯背一段class继承示例，在面试官心里可信度高得多。
4. 面试追问的高频分支：super指向、箭头函数、内置构造器继承
4.1 super在不同场景下到底指向谁
super的指向问题几乎是必考分支。第一层理解：super在构造函数中代指父类构造器，所以可以传入参数完成父类实例属性初始化。第二层理解：super在普通方法中代指父类原型对象，可以访问父类原型上的方法。
class Parent { log() { return 'parent-log'; } } class Child extends Parent { log() { let p = super.log(); // super 是 Parent.prototype return 'child-' + p; } } new Child().log(); // 'child-parent-log'第三层理解更隐蔽：super在静态方法中代指父类构造器本身。所以父类静态方法内部通过super调用另一个静态方法是可行的：
class Parent { static hi() { return 'static-hi'; } static callHi() { return super.hi(); } } class Child extends Parent {} Child.callHi(); // 'static-hi'这个知识点面试中答出来，基本能证明你对super的语义不是背能背出来的。我还遇到过实战场景：多层继承中，子类static方法需要调用父类static配置进行合并，用super就非常优雅，同时避免了硬编码父类名导致的重构隐患。
4.2 类内部为什么用不了箭头函数做方法
有候选人说“class里写箭头函数也能实现方法啊”，语法上确实能写：
class Foo { bar = () => { console.log(this); }; }但注意，这里的bar不是挂在Foo.prototype上，而是作为实例属性存在的。再看类方法定义：
class Bar { bar() {} }后者才挂在原型上，才是可以被子类继承并重写的“类方法”。前者是每个实例创建时都会被重新赋值一次的实例属性，内存上每实例一份，而且不能被子类原型方法直接覆盖。如果面试中遇到箭头函数定义类方法的代码，这就是讨论点：箭头函数捕获的是类实例的this，好处是作为事件回调时不会被改变指向，但代价是放弃了原型继承的方法共享机制，也不利于子类通过super访问父类版本。实际项目里如果不需要动态this语义，或者主要在类外调用实例方法，原型方法优先。需要接收事件回调绑定的场景，箭头实例字段值得用。但面试官问“箭头函数能做类方法吗”时，说“能做但变了语义”永远是比“能”或“不能”更完整的回答。
4.3 继承Array/Error这些内置类型时的坑
ES6之前，原生构造器几乎不可能被子类正确继承——Array构造器返回的数组对象不理会自定义原型。ES6 class面向内置类型做了新机制，终于可以这样写了：
class MyArray extends Array { first() { return this[0]; } } let arr = new MyArray(1, 2, 3); arr.first(); // 1但坑也随之而来。数组的map、filter、slice等方法返回的是新数组，这个新数组的类型由Symbol.species决定。默认设置下，species指向构造器本身，所以返回值就是MyArray实例，可以继续调用first()。如果不希望返回子类类型，可以手动配置：
class MyArray extends Array { static get [Symbol.species]() { return Array; } }这样map出来的结果变成原生数组，first()就没了。
继承Error也有类似模式。直接在自定义错误类里重写name、message，或者利用message参数传递上下文，都是很实用的做法。
class ValidationError extends Error { constructor(message, field) { super(message); this.name = 'ValidationError'; this.field = field; } }这类内置类型继承题不在少数，尤其是大型项目里需要自定义数据结构和错误体系时，掌握这一节非常有用。我在面试中经常出“怎么设计一个带校验逻辑的数组子类”这种题，能答出Symbol.species的人，代码底子基本是扎实的。
5. 现实业务里的继承设计：mixin、组合与继承的选择权
5.1 多层继承和mixin混入的实现
class只支持单继承，但业务里经常会遇到“我希望这个类同时有多个来源的能力”。这时mixin模式是常见方案。把一组方法打包成一个函数，返回一个能混入的基类：
const Loggable = (Base) => class Loggable extends Base { log(msg) { console.log(`[${this.name}] ${msg}`); } }; const Printable = (Base) => class Printable extends Base { print() { console.log(this.name + ' printable'); } }; class Entity {} class User extends Loggable(Printable(Entity)) {}注意mixin的嵌套顺序会影响继承链形态和优先级。常用规则是：能力越基础越放在靠近Entity的一侧，越具体越靠外层。如果多个mixin都定义了同名方法，最外层mixin的版本会生效。这种组合方式比无限制地挖继承层级更灵活，也不容易造成“父类里堆一堆无关功能”的味道。实际项目里把这类mixin放在一个独立的“能力包”目录里，通过函数组合维护，比单纯堆继承层次清晰得多。
5.2 过度继承带来的问题：菱形冲突与职责混乱
现实中见过一个工具类深挖了五层：A继承B，B继承C，C又继承D，D继承E。改底层E的一个方法签名，上三层全部报错。这种“继承深度依赖”非常脆弱。菱形冲突在JS中没有语言层面的解决机制，同名方法的覆盖顺序完全由原型链线性决定，很容易出现意外覆盖。尤其是mixin模式中两个mixin意外定义了相同名称的辅助方法时，排查起来异常痛苦。
所以我的经验法则是：继承适合“稳定的、真正is-a的关系”，比如“管理员是一种用户”；如果只是“需要有日志能力”“需要可打印”这类横切能力，优先用mixin或组合而非继承。组合思路是让类持有能力对象：
class User { constructor(name) { this.name = name; this.logger = new Logger(); } save() { this.logger.log('保存用户'); } }代码更平淡，但组件间的耦合更少，替换实现也更方便。面试里能主动说出“不是所有复用都要靠继承，组合和mixin怎么取舍”，是很成熟的工程信号。
6. 把这些答成一道面试题：现场答题框架与加分点
6.1 答题顺序建议和踩分点分布
如果是面试中被问到“说说ES6的继承”，我会按这个顺序组织答案：
首先给一个最小可运行的类继承示例，带动画出构造函数、方法、静态成员的继承调用。然后讲extends背后做的事：原型链自动连接、构造器必须先调用super、静态属性通过原型链继承。接下来用ES5寄生组合继承做对比，点出class在正确性、静态成员、构造器机制三个层面的改进。再补充super的两种指向和内置类型继承的注意事项，最后落到工程实践：mixin组合、继承平面化设计。
这个回答骨架能从语法、原理、对比、实战四个层次覆盖问题，面试官很难在你完整走完这套后还觉得你“只是背过”。加分项包括：主动提到super()必须在构造器里最先出现，并解释this初始化的原理；能用手画出原型链；提及Symbol.species时展示了超出常规的前端深度。
6.2 高频追问清单和提示
可能被追问的清单整理如下：
- 子类构造器不写super会怎样——不写constructor就不会报错；写了constructor就必须在第一行super，否则运行时错误
- super在箭头函数里能用吗——箭头函数没有自己的super绑定，它会继承外层函数的super
- class声明会提升吗——不会，类声明类似let，存在暂时性死区
- 类方法是可枚举的吗——class定义的方法是内部设置为不可枚举的，与ES5直接赋prototype方法默认不同
- 继承后instanceof如何判断——子类实例对父类构造器的instanceof为true，因为原型链包含父类.prototype
- 能直接覆盖父类方法吗——可以，子类重写同名方法即可，用super调用父类版本也能协同工作
这些问题看着细，但都指向同一个核心：你是否理解class继承是建立在原型链之上的一套规范化机制。把第一节的原型链视角吃透，这些追问其实都能推导出来。
6.3 面试之外的启发：继承的边界感
把ES6继承玩得熟练之后，最大的收获不只是面试加分，而是建立了一种判断力：什么时候该extends，什么时候该组合，什么时候该mixin。继承是整个JS对象体系的缩影，它的一招一式都源于原型链这个基本模型。理解了这些，你再看React类组件的继承设计、再看各种类库里的基类抽象，都会有种“这里为什么这样写”的会心感。
如果你正在准备面试，建议别只把代码背熟，自己动手用ES5写一遍继承，再用class改写，对比两者差异。这个动手过程带来的理解深度，比看十篇面试题解析都有用。
