JavaScript构造函数忘记写new会导致什么错误

在 JavaScript 中，调用构造函数时如果遗漏了 new 操作符，该函数将直接作为普通函数被执行。这意味着原本由运行时自动完成的新对象创建、原型继承绑定以及实例上下文注入机制完全不会触发。由此引发的后果非常明确：在非严格模式下，函数内的 this 会直接绑定到全局对象并造成隐蔽的全局属性污染，且函数默认返回 undefined，导致后续属性读取抛出空引用异常；在严格模式下，this 为 undefined，试图赋值时会立即抛出类型错误（TypeError）。理解这一错误的底层机理，并在现代工程中采用防御式设计或原生语法约束，是避免此类问题的关键。

一、new 运算背后的实例化机制对比

要透彻理解漏写 new 导致的错误，首先需要厘清 new 操作符在背后到底执行了哪些操作。在 JavaScript 语言规范中，以构造方式调用一个函数与以普通函数方式调用一个函数，底层所触发的内部调用入口是不同的。

当使用 new Func() 调用时，JavaScript 引擎会严格执行以下四个步骤：

1. 创建新对象：在内存中开辟一块空间，创建一个全新的普通 JavaScript 对象 {}。
2. 建立原型链关联：将这个新对象的内部隐藏属性 [[Prototype]]（即开发中常用的 __proto__）指向构造函数的 Func.prototype。
3. 重定向 this 指针：将构造函数内部的执行上下文 this 强制绑定到刚才创建的新对象上，随后执行构造函数内部的代码逻辑。
4. 返回实例：检查构造函数内部的返回值。如果函数显式返回了一个引用类型对象，则最终返回该对象；否则，自动返回步骤 1 中创建的新对象。

然而，当开发者漏写了 new，直接执行 Func() 时，上述步骤全部失效。函数仅作为普通函数调用，this 遵循常规函数的默认上下文绑定规则，且由于构造函数通常不需要显式声明 return，函数运行结束后的返回值默认为 undefined。

二、具体错误表现与执行环境差异

当 new 被遗漏后，程序表现出的具体报错形态完全取决于当前的 JavaScript 代码是否启用了严格模式（Strict Mode）。不同执行环境下的行为表现截然不同。

1. 非严格模式：全局变量污染与静默延迟崩溃

在传统的非严格模式下，普通函数调用若未指明调用者（如 User("Bob")），函数体内的 this 会默认指向全局对象——在浏览器环境中为 window，在 Node.js 环境中为 global（现代标准中统一为 globalThis）。

function User(name, age) {
  this.name = name;
  this.age = age;
}

// 错误调用：忘记写 new
const user = User("Bob", 25);

console.log(user); // 输出: undefined
console.log(window.name); // 输出: "Bob" (全局变量被意外写入)
console.log(window.age);  // 输出: 25

// 后续业务代码调用
console.log(user.name); // 抛出异常：TypeError: Cannot read properties of undefined

此场景下的错误危害最为严重，主要表现为三点：

• 污染全局命名空间：构造函数内所有本意挂在实例上的属性（如 this.name、this.age），被直接写入全局作用域。在浏览器环境中，window.name 是一个原生属性（用于窗口跳转或框架通信且只能存储字符串），对其意外赋值可能直接导致页面的其他通信逻辑破坏。
• 返回值为空导致滞后崩溃：User 函数未指定 return 语句，因此变量 user 实际接收到的值为 undefined。代码在赋值时并不报错，直到后续业务试图读取 user.name 或调用其原型方法时，才突然抛出 TypeError: Cannot read properties of undefined (reading 'name')。这种“发病点与病灶分离”的现象排查成本极高。
• 破坏面向对象特性：由于没有生成实例，user instanceof User 会直接报错；原本在 User.prototype 上定义的公共方法完全无法被该调用结果访问。

2. 严格模式：构造函数内部立即抛出类型异常

在启用了 "use strict"; 的严格模式下，JavaScript 取消了普通函数调用时 this 自动指向全局对象的宽松策略。此时独立运行的普通函数，其内部的 this 将严格保持为 undefined。

"use strict";

function User(name, age) {
  // 此时 this === undefined
  this.name = name; // 直接报错！
  this.age = age;
}

// 错误调用
const user = User("Bob", 25);
// 控制台输出错误：
// Uncaught TypeError: Cannot set property 'name' of undefined (Chrome / Node)
// 或 TypeError: this is undefined (Firefox)

在严格模式下，尝试在 undefined 上挂载属性会使 JavaScript 引擎立即中断执行并抛出类型错误。与非严格模式相比，严格模式的优势在于“故障即刻显现”，错误直接抛在构造函数的第一行赋值语句上，使得开发者能够通过报错调用栈迅速发现根本原因，避免了难以捉摸的全局变量污染。

三、内置构造函数的特例与混淆行为

在日常开发中，有些开发者可能会发现自己即使不写 new，某些构造函数依然能够正常工作，这往往导致对 new 的必要性产生认知偏差。事实上，JavaScript 原生内置对象在处理不带 new 的调用时，内部存在截然不同的分流逻辑：

内置对象分类	典型代表	不写 new 时的行为表现	结果与带 new 是否一致
内置防御型构造器	Array(), RegExp(), Error()	内部自动识别并代理为 new Array() 等构造行为，返回实例对象。	一致，均返回合法实例。
类型转换函数	Number(), String(), Boolean()	作为强制类型转换函数使用，返回对应的基础原始值（Primitive Value）。	不一致。带 new 返回包装对象，不带 new 返回原始值。
单例/特定语义函数	Date()	不论传入何种参数，均直接返回当前系统时间的纯字符串。	完全不一致。带 new 返回 Date 实例对象，不带 new 返回字符串。
开发者自定义构造函数	普通自定义函数（未加防护）	作为普通函数调用，this 丢失，返回 undefined 或抛出异常。	完全不一致，导致严重逻辑异常。

四、四种防御与重构修复方案

为了从根本上杜绝忘记书写 new 所带来的故障，现代 JavaScript 生态提供了从语言规范级别到代码质量检查的多层次防护手段。

方案一：全面迁移至 ES6 Class 语法（现代开发首选）

ECMAScript 2015 (ES6) 引入的 class 关键字从语法层面彻底消除了该问题。在 ECMAScript 规范中，类构造函数具有内部属性 [[Construct]]，但被显式移除了普通函数具备的 [[Call]] 调用能力。

class User {
  constructor(name) {
    this.name = name;
  }
}

// 错误调用：尝试不加 new 调用类
const user = User("Alice");
// 运行直接报错：
// Uncaught TypeError: Class constructor User cannot be invoked without 'new'

只要未加 new 调用类，JavaScript 引擎会在运行时抛出明确的 TypeError，绝不允许代码带着错误的上下文向下执行。这是目前最具生产力、最符合工程直觉的方案。

方案二：使用 new.target 元属性进行自适应实例化（函数场景推荐）

如果在某些库或特定架构中必须保持构造函数形式，可以使用 ES6 提供的元属性 new.target。当函数通过 new 运算符被调用时，new.target 指向该函数自身；若是普通函数调用，new.target 的值则为 undefined。

function User(name) {
  // 检查是否通过 new 触发
  if (!new.target) {
    // 若未写 new，自动代理并返回正确的实例
    return new User(name);
  }
  this.name = name;
}

// 无论写不写 new，均能正确获得 User 实例
const u1 = new User("Alice");
const u2 = User("Bob");

console.log(u1 instanceof User); // true
console.log(u2 instanceof User); // true
console.log(u2.name);            // "Bob"

通过 new.target，函数可以做到“自适应实例化”，既保护了自身上下文不被泄露到全局，又为调用者提供了极大的宽容度。

方案三：传统 ES5 环境下的 instanceof 判定守卫

在旧版不支持 ES6 语法的历史工程中，开发者常通过检查 this 是否属于当前构造函数的实例来实现类似效果：

function User(name) {
  if (!(this instanceof User)) {
    return new User(name);
  }
  this.name = name;
}

方案四：引入 ESLint 静态代码检查规则

通过工程化工具将错误拦截在代码编写阶段，是性价比最高的方式。在项目的 .eslintrc.json 中启用以下规则：

{
  "rules": {
    "new-cap": ["error", { "newIsCap": true, "capIsNew": true }],
    "no-caller": "error"
  }
}

其中 newIsCap: true 强制所有以大写字母开头的函数调用必须附带 new；capIsNew: true 则规定大写函数不可像普通函数那样直接执行。配置后，漏写 new 的代码在编辑器提示及 CI 流水线构建时就会直接报错报警。

五、总结与行为对照矩阵

总结来说，JavaScript 构造函数忘记写 new 是语言弱类型与灵活上下文机制交织产生的典型陷阱。下表对各种调用场景及防御手段的行为结果进行了整体汇总：

在日常开发中，针对“构造函数忘记写 new 会导致什么错误”这一问题，可以归纳出清晰的处置与自查要点：

• 出现 TypeError: Cannot set property '...' of undefined，优先排查构造函数调用处是否缺失 new 导致 this 丢失。
• 出现 TypeError: Cannot read properties of undefined，检查接收实例的变量是否因漏写 new 而接收到了默认的 undefined。
• 新编写的模块应遵循现代 JavaScript 规范，全面采用 class 声明对象类型，将运行时的偶发疏漏转变为编译器与引擎级别的硬性阻断。