近日，一句看似简单的话“Inheritance doesn't work without using new”在技术社区悄然走红。对于许多正在学习JavaScript面向对象编程的开发者来说，这句话不啻为一记警钟：难道继承机制真的完全依赖于new关键字吗？要回答这个问题，还得从JavaScript的class语法说起。
经典错误：Class constructor cannot be invoked without 'new'
当开发者尝试直接调用一个类（class）的构造函数，而非通过new实例化时，现代浏览器控制台会抛出一个明确的错误：“Class constructor cannot be invoked without 'new'”。这句话正是标题“Inheritance doesn't work without using new”的原始出处。以一段典型的继承代码为例：
class Animal {}
class Dog extends Animal {}
// 错误用法：没有使用 new
let d = Dog(); // TypeError: Class constructor cannot be invoked without 'new'
即便Dog本身没有定义构造函数，它作为Animal的子类，也必须通过new Dog()来创建实例。这意味着，在JavaScript的class体系中，继承链条上的每一个环节都默认绑定在new语义之上。
为什么继承离不开new？
要理解这一设计，需回溯JavaScript的原型链机制。new关键字在调用构造函数时，会执行四个步骤：创建一个空对象，将该对象的原型指向构造函数的prototype属性，将this绑定到该对象，并执行构造函数体。ES6引入的class语法本质上是构造函数的语法糖，但相较于ES5的普通函数，class构造器在执行时有一个关键区别：它只能通过[[Construct]]内部方法调用，而不能通过[[Call]]调用。也就是说，class构造函数被强制要求必须使用new，否则引擎直接拒绝执行。
这一设计并非随意为之。在class继承中，子类的this对象必须先由父类构造函数通过super()完成初始化。如果允许直接以普通函数方式调用子类，this将无法正确绑定，更遑论从父类继承的属性与方法。JavaScript语言规范因此引入了“类只能被new调用”的限制，从底层杜绝了意外滥用。
开发者面临的实际困境
虽然这种设计是安全性考量，却也给开发者带来了一些不便。尤其是在函数式编程风格盛行的今天，许多开发者习惯将构造函数当作普通函数调用，或通过高阶函数动态创建实例。例如，在使用Array.prototype.map或setTimeout等需要回调函数的场景中，如果无意中把class构造函数直接传入，就会触发上述错误。
此外，对于继承场景，一些开发者尝试绕过new，例如使用Object.create(Child.prototype)或修改原型链，但这些做法往往偏离class语法预设的轨道，导致子类实例无法正确继承父类的内部属性，甚至出现原型链断裂的诡异问题。正如一位参与讨论的资深工程师所言：“你可以用各种技巧模仿继承，但class的设计初衷就是让你明确使用new。不尊重这一基础，就等于和语言规范对着干。”
如何正确解决？
针对这一问题，最直接的解决方案自然是：坚持在实例化时使用new关键字。对于确实需要无new调用的场景，开发者可以封装一个工厂函数，或者使用Reflect.construct方法：
function createDog() {
return Reflect.construct(Dog, []);
}
let d = createDog(); // 正常创建实例
但值得注意的是，无论采用哪种变通手法，其底层仍无法摆脱new的语义。JavaScript官方委员会甚至在提案中明确表示，class构造器不可作为一个普通函数调用，这一规则“不会改变，也不应改变”。其目的在于帮助开发者在编译期间暴露错误，而非在运行时静默失败——这是在为长期维护的代码质量负责。
影响与启示
这一现象折射出JavaScript面向对象编程的一个核心悖论：继承机制看似天经地义，却完全依赖new这一单一入口。对于已经习惯了Java或C++等传统面向对象语言的程序员来说，这种约束可能显得格外严格；但正是这种严格要求，使得JavaScript的继承关系更为透明、可预测。
近年来，前端社区关于“是否应该继续使用class继承”的争论从未停歇。支持者认为class语法简洁直观，反对者则推崇组合优于继承。但无论立场如何，一个不争的事实是：在class成为语言核心的今天，任何继承尝试都离不开new。正如那句流传的警示语所告诉我们的——没有new，继承大厦的基石便不复存在。理解这一点，或许比掌握各种设计模式更为重要。