JavaScript箭头函数不能作为构造函数的原理

为什么箭头函数不能通过 new 关键字调用？这并不是语法错误或浏览器兼容性问题，而是 JavaScript 引擎在底层就阻止了它进入构造流程——这一设计从 ES6 规范制定之初就被确定下来。

箭头函数根本不存在 [[Construct]] 内部方法

引擎判断一个函数是否能够被 new 调用，只取决于它是否拥有 [[Construct]] 这个内部方法：

• 普通函数（function 声明或表达式）以及 class 在创建时，会自动携带 [[Construct]] 内部方法；
• 箭头函数在 ECMAScript 规范中被明确排除——其内部方法列表仅包含 [[Call]]，而不包含 [[Construct]]；
• 当执行 new arrowFn() 时，引擎会立即检查到缺少该能力，随即抛出 TypeError: xxx is not a constructor 错误，函数体根本不会被执行。

箭头函数缺少 prototype 属性

构造函数必须提供一个可访问、可配置的 prototype，用来建立实例的原型链：

• 执行 console.log((() => {}).prototype) 会返回 undefined；
• 即便尝试手动赋值 arrowFn.prototype = {}，在严格模式下也会静默失败，非严格模式下同样无效；
• 缺少 prototype 属性意味着新创建的对象无法通过 __proto__ 链接到它，从而切断了原型链继承机制。

箭头函数缺少构造所需的上下文绑定

构造调用依赖一套完整的运行时上下文，箭头函数在这方面全部缺失：

• this 是词法作用域绑定的，无法在 new 调用时动态指向新创建的实例；
• arguments 对象不存在，因此无法访问传入的实参；
• new.target 始终为 undefined，无法判断当前是否通过构造调用；
• super 不可用，导致在子类中无法正确执行父类的构造逻辑。

这是语言设计者有意做出的选择

ES6 引入箭头函数的初衷非常明确：提供一种轻量、无状态、专注于计算的函数表达式，特别适用于回调、数组映射、事件处理等场景。

• 放弃构造能力旨在避免语义混淆——例如防止开发者错误地将 () => ({}) 当作构造器使用（该表达式返回的是字面量对象，而非实例）；
• 避免 this 的词法绑定与构造函数中的动态绑定产生冲突；
• 保持语言行为的清晰与可预测：需要定义类型时使用 function 或 class；需要简洁的回调时则使用箭头函数。