es6 class 语法无运行时损耗，但 extends 继承链显著降低性能：单层调用降53%，两层降79%，三层仅剩不足20%；super 调用有真实开销，高频场景应优先组合、缓存或避免多层继承。
ES6 class 语法本身不引入运行时性能损耗，但 extends 继承链会带来可观测的执行开销，尤其在高频调用、深度继承或严苛性能场景下需谨慎评估。
继承层级直接影响方法调用速度
实测数据（Node v8.9.4）显示：单层 extends 会使简单方法调用性能下降约 53%；两层继承下降约 79%；三层继承后性能仅剩原始类的不到 20%。这不是语法“错误”，而是 V8 引擎对 class 继承链的属性查找路径更长、内联优化受限所致。构造函数实例化同样变慢，且继承层数越多，差距越明显。
- 避免为复用少量方法而滥用多层 class 继承
- 若只需扩展行为，优先考虑组合（composition）或 mixin 模式
- 高频核心逻辑（如序列化器、渲染器、编解码器）中，慎用超过一层的 extends
class 是语法糖，但 super 调用有真实成本
super.method() 不是简单跳转，它涉及动态确定原型链上的目标方法、检查 this 绑定、触发可能的代理拦截等步骤。相比直接调用父类构造函数（Parent.call(this, ...)）或手动绑定原型方法，super 在热路径上会产生额外开销。尤其在循环体内或递归调用中，差异会被放大。
- 性能敏感代码中，可将
super.xxx提前缓存为局部变量（如const parentMethod = super.method.bind(this)），但需权衡可读性 - 重写父类方法时，若逻辑简单且不依赖 super 的动态语义，可考虑复制粘贴 + 微调，而非无条件 super 调用
静态分析工具能提前暴露风险
像 EStimator.dev 这类工具，可对项目源码做 AST 级扫描，自动识别 class 继承深度、super 使用频次、以及潜在的原型链过长问题，并估算切换现代语法后的体积与执行效率变化。它不替代 benchmark，但能批量发现“隐性高开销点”，比如某个被 20 个子类继承的基类，就是值得重构的信号。
- 接入 CI 流程，在 PR 阶段对新增 class 继承结构做深度检查
- 结合项目实际运行环境（如目标 Node 版本、是否启用 TurboFan 优化）配置分析阈值
- 重点关注被大量实例化或频繁调用的类，而非一次性使用的工具类
不是拒绝 class，而是理解它的代价边界
class 极大提升了可维护性与协作效率，绝大多数业务代码无需担忧其开销。真正需要警惕的是：把 class 当作“免费抽象”，在性能关键路径上堆叠多层继承、过度使用 super、或在毫秒级响应要求的模块（如游戏循环、实时音视频处理）中盲目套用 OOP 模式。此时，回归构造函数 + 显式原型操作，反而更可控、更高效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
