es6 extends 子类实例化存在显著性能开销，单层继承比纯类慢50%～60%，两层慢75%～80%，三层及以上呈非线性衰减；根本原因在于v8需每次new时沿原型链查找并绑定上下文，且super()触发额外检查。
ES6 extends 子类实例化确实存在可测量的性能开销，尤其在高频创建或深度继承场景下不可忽视。
继承层数直接影响实例化速度
每多一层 extends，实例化耗时明显上升。实测数据显示：
- 单层继承（
B extends A）比纯类A慢约 50%～60% - 两层继承（
C extends B extends A）比A慢约 75%～80% - 三层及以上时，性能衰减趋于非线性，部分版本 Node 中甚至接近“断崖式”下降
根本原因在于 V8 对 ES6 类继承链的初始化逻辑更重：每次 new 都需沿原型链向上查找并绑定构造上下文，且子类构造函数必须显式调用 super()，触发额外的检查与代理操作。
对比其他继承方式更慢
相同功能下，extends 通常比传统方案慢：
-
util.inherits或手动Object.setPrototypeOf实现的继承，性能更稳定，受层数影响小 - 纯构造函数 + 原型赋值（如
Foo.prototype = Object.create(Bar.prototype)）也普遍快 2–3 倍 - ES6 class 无继承的写法本身很快，性能损失几乎全来自
extends机制本身
高频实例化场景要特别谨慎
以下情况建议规避深层 extends：
- 序列化/反序列化器（如 hessian、protobuf 解析器）中频繁 new 实例
- 游戏循环、动画帧、实时数据处理等毫秒级敏感路径
- 工具类、DTO、临时包装对象等生命周期短、数量大的对象
可考虑替代方案：组合优于继承、工厂函数返回普通对象、或用 Object.assign 复用行为而非继承结构。
类型判断不受性能影响，但需注意语义
虽然实例化变慢，但 instanceof 判断依然准确高效：
-
new B() instanceof A和instanceof B都返回true - 原型链完整，不影响类型校验逻辑
- 但
typeof对所有 class 实例都返回"object"，不能用于区分具体类
所以类型安全没问题，只是创建成本高——该用的地方照用，但别为“看起来更 OOP”而无谓加深继承。
