性能差异可忽略，Class与构造函数底层机制一致、执行路径相同，引擎优化相当；微小初始化开销仅纳秒级，真正影响性能的是代码逻辑而非语法选择。
JavaScript 中 class 语法和函数原型继承在运行时性能上几乎没有差异。两者最终都依赖相同的原型机制，引擎（如 V8）对它们的处理路径一致，优化手段也完全相同。
方法调用开销基本一致
类中定义的非静态方法会自动挂载到 Class.prototype 上，和手动写 MyClass.prototype.method = function() {} 效果一样。引擎通过内联缓存（IC）快速定位原型上的函数，查找过程不因“写在 class 里”而变慢。
- obj.method() 的执行流程：查实例 → 查 prototype → 执行，无论 method 是 class 定义还是 prototype 手动添加
- 静态方法（
static foo()）等价于直接挂在构造函数上的函数，和顶层声明的普通函数无区别 - 真正影响性能的是调用方式，比如在循环中反复创建实例、滥用箭头函数绑定、或 getter 内做同步耗时操作
构造与初始化才是瓶颈所在
性能差异通常不出现在“怎么定义方法”，而出现在“怎么创建对象”和“初始化做了什么”。
- class 构造函数中执行大量计算（如生成大数组、深克隆对象），会拖慢 new 实例的过程
- 用构造函数 + prototype 方式时，如果在 constructor 里重复 new 对象或遍历长数组，同样会卡顿
- 两者在构造阶段的开销取决于你写的逻辑，而不是语法形式
内存与可枚举性有细微差别
class 语法默认让方法不可枚举，而手动挂到 prototype 上的方法默认可枚举——但这只影响 for...in 或 Object.keys()，不影响执行速度。
立即学习“Java免费学习笔记（深入）”；
- 不可枚举性是语义层面的设计选择，不是性能优化措施
- 若需手动模拟 class 行为，可用
Object.defineProperty设置enumerable: false - 这种差异对日常业务代码几乎无感知，也不会带来 measurable 的性能变化
该选哪个，取决于工程需求而非性能
现代 JS 引擎对 class 和原型写法一视同仁。选择标准应是可读性、协作效率和长期维护成本。
- 新项目、团队协作、对接 TypeScript 或主流框架（React/Vue），优先用 class + extends
- 需要动态修改原型、实现对象直继承（
Object.create(obj)）、或调试底层行为时，才需回到原型操作 - 手写寄生组合式继承或阅读 Babel 编译后的代码，有助于理解 class 背后发生了什么，但不改变实际性能表现
