ES6 class 是当前工程实践基准线，其 extends + super 机制确保构造函数单次调用、可传参、可控；方法必须定义在 prototype 或 class 顶层以复用内存，实例属性（含引用类型）须在 constructor 中初始化以避免共享；禁用原型链继承、手动寄生组合及动态绑定方法，装饰器仅限纯函数横切用途。
制定现代 JavaScript 继承选型白皮书，核心不是比“谁更新”，而是看“谁更稳、更省、更可控”——尤其在内存复用与执行效率双重要求下。ES6 class 是当前工程实践的基准线，但它只是语法糖；真正影响性能的是底层如何组织原型链、是否重复创建方法、引用属性是否意外共享、构造函数是否被冗余调用。白皮书应聚焦可测量、可验证、可落地的继承策略，而非罗列所有历史方案。
明确内存复用的关键落点
JavaScript 中最显著的内存开销来自方法副本和引用类型属性共享。V8 引擎测试表明：10,000 个实例下，原型方法比构造函数内定义的方法节省约 78% 内存。因此白皮书需强制区分两类成员：
- 实例属性（含引用类型）必须在 constructor 中初始化，确保每个实例独占副本，避免数组/对象被多个实例误改；
- 方法与只读共享属性必须定义在 prototype 或 class body 的顶层，由所有实例沿原型链共用，不随 new 操作重复分配；
- 禁止在子类 constructor 中重复定义父类已有的方法，也不应在原型上动态添加方法（影响 JIT 编译优化）。
约束构造函数调用频次与参数传递能力
继承方案若无法向父类传参，或导致父类构造函数被调用多次（如组合继承中两次调用 SuperType），就会引发初始化逻辑错乱或资源浪费。白皮书应规定：
- 子类 constructor 必须通过 super(...args) 显式调用父类构造函数，且仅一次；
- 拒绝使用
SubType.prototype = new SuperType()这类原型链继承，因其在设置原型时即执行父类构造函数，且无法传参； - ES6 class 的
extends+super是唯一默认满足“单次、可控、可传参”的构造流程，应作为基线要求。
禁用易引发内存泄漏的模式
某些看似简洁的继承写法，在长期运行或高并发场景下会暴露隐患：
立即学习“Java免费学习笔记（深入）”；
- 避免在原型上直接挂载闭包或绑定 this 的方法（如
prototype.fn = function() { ... }.bind(this)），每次 new 都生成新函数，破坏复用； - 禁用寄生组合继承的手动实现（如
Object.create(Super.prototype)配合call），除非有特殊兼容需求——现代环境完全可用class替代，手动实现反而增加出错概率； - 私有字段（
#field）和静态块（static { ... }）可安全用于封装初始化逻辑，但不得在私有字段中存储大型缓存对象，防止实例膨胀。
面向未来的可扩展性边界
ES2024 装饰器已进入 Stage 4，支持在类定义期修改继承行为（如自动注入 mixin、重写 super 调用）。白皮书应预留接口，但设限使用：
- 装饰器仅用于横切关注点（如日志、权限校验），不得改变原型链结构或覆盖
constructor行为； - 所有装饰器必须是纯函数，无副作用，且可通过 Babel / SWC 稳定降级到 ES2020；
- 禁止用装饰器替代
extends实现“伪多继承”，JavaScript 仍为单原型链语言，强行模拟会破坏 instanceof 判断与调试体验。
