JavaScript实例化忘记加new会导致什么错误

一、传统构造函数漏加 new 的底层机制与错误表现

在 ES6 普及之前，JavaScript 通过普通函数充当构造函数。当我们使用 new Func() 调用时，引擎会自动创建新对象、绑定原型，并将函数体内的 this 绑定到该新对象上。然而，如果忘记写 new，该函数就退化成了普通函数调用，函数的执行环境与返回值将彻底脱离预期。

1. 非严格模式：全局变量污染与延迟性 TypeError

在没有开启严格模式的代码中，直接调用构造函数会导致函数内部的 this 默认指向全局对象（在浏览器中为 window，在 Node.js 中为 global）。

// 定义传统构造函数
function User(name, role) {
  this.name = name;
  this.role = role;
}

// 错误示范：忘记添加 new 关键字
const alice = User('Alice', 'Admin');

// 检查变量返回值
console.log(alice); // 输出：undefined

// 后续业务代码尝试访问属性
console.log(alice.name); 
// 抛出运行时崩溃：Uncaught TypeError: Cannot read properties of undefined (reading 'name')

// 检查全局作用域被污染的情况（以浏览器环境为例）
console.log(window.name); // 输出："Alice"（意外覆盖了 window.name 原生属性）
console.log(window.role); // 输出："Admin"

这种错误具有很强的隐蔽性与破坏性。首先，构造函数本身没有 return 语句，普通函数默认返回 undefined，因此接收变量 alice 实际上是 undefined。错误并不会在调用时立刻暴露，而是在后续使用该实例变量（如 alice.name）时才抛出 TypeError。其次，原本属于实例的私有属性全部被强行挂载到了全局对象上，可能导致全局状态混乱或覆盖原生全局属性。

2. 严格模式：即时触发 TypeError 异常

如果脚本或构造函数顶部声明了 "use strict";，JavaScript 引擎会禁止 this 默认回退到全局对象，此时普通调用中的 this 为 undefined。

"use strict";

function Product(title, price) {
  this.title = title; // 报错所在行！
  this.price = price;
}

// 忘记加 new 调用
const item = Product('Mechanical Keyboard', 299);
// 立即抛出：Uncaught TypeError: Cannot set properties of undefined (setting 'title')

在严格模式下，当执行到 this.title = ... 时，引擎发现 this 是 undefined，会立即阻断执行并抛出类型错误。虽然程序同样崩溃，但由于报错位置准确锁定在构造函数内部，开发者能够第一时间定位到漏写 new 的问题所在。

图 1：普通构造函数在加 new 与漏加 new 两种情况下的底层执行与影响差异

二、ES6 Class 与内置对象的特殊报错行为

随着 ECMAScript 规范的发展，现代 JavaScript 引入了 class 关键字，同时各类内置构造函数在没有 new 时的处理机制也不尽相同。

1. ES6 Class 的语言级防护：明确拦截报错

为了从根本上规避传统构造函数漏写 new 造成的全局污染，ES6 规范为类构造函数增加了内部槽 [[IsClassConstructor]]。如果尝试像普通函数一样直接调用类，引擎会立刻抛出明确的语法级限制报错：

class OrderManager {
  constructor(orderId) {
    this.orderId = orderId;
  }
}

// 错误示范：忘记加 new
const manager = OrderManager('ORD-20261001');
// 控制台直接报错：
// Uncaught TypeError: Class constructor OrderManager cannot be invoked without 'new'

这一机制保证了使用 class 声明的代码永远不会误入普通函数的执行流，从语法层面杜绝了全局变量被意外篡改的隐患。

2. 原生内置对象的差异化表现

JavaScript 的标准内置构造函数对 new 的依赖程度存在明显分化，漏写 new 时的表现因对象而异：

• Date 对象：调用 new Date() 返回 Date 对象实例；若漏写 new 直接调用 Date()，它将忽略所有传入参数，仅仅返回当前系统时间的纯字符串。后续若调用 date.getFullYear() 等方法，会直接报错 TypeError: date.getFullYear is not a function。
• 基本类型包装器（String / Number / Boolean）：使用 new Number(123) 会生成对应的对象包装器；如果不加 new，例如 Number("123")，则退化为强制类型转换函数，返回原始数字 123，而非对象。
• 容错型构造函数（Array / RegExp / Error / Object）：这些内置对象在底层实现了自适应判断，无论是否添加 new，都会安全返回新的对象实例（例如 Array(3) 等价于 new Array(3)）。
• 禁止使用 new 的构造器（Symbol / BigInt）：这两种原始类型为了防止开发者创建冗余的包装对象，直接在规范层面禁止搭配 new 使用，若强行加上 new Symbol()，反而会抛出 TypeError: Symbol is not a constructor。

图 2：不同 JavaScript 结构与内置对象在遗漏 new 时的行为对照表

三、排查与定位漏写 new 错误的实战流程

当生产或测试环境抛出类似 Cannot read properties of undefined 或 Class constructor cannot be invoked 的堆栈信息时，应按照以下具体步骤迅速定位并验证问题：

1. 分析报错日志中的异常特征： 如果报错信息明确包含 Class constructor ... cannot be invoked without 'new'，直接跳转到调用处补全 new 关键字；如果信息是 Cannot read properties of undefined (reading 'xxx')，则需要根据报错行向上反查持有该属性的变量来源。
2. 检查实例变量初始化语句： 查看该变量赋值处是否存在 const obj = MyConstructor(...) 的写法。如果在函数调用前缺少 new，说明变量实际接收到的是 undefined。
3. 审查构造函数内部与运行模式： 查看目标函数的首行是否使用了 "use strict"，判断是否造成了 this 挂载失败；同时确认该函数是否预期通过 new 实例化，若函数本身是大驼峰命名（PascalCase），几乎可以断定为构造函数。
4. 排查潜在的全局作用域污染： 如果项目在非严格模式下运行，在浏览器控制台中打印 window 或对应模块上下文，排查是否存在与构造器内部属性同名的全局脏变量，评估是否有其他业务逻辑已被篡改。
5. 回归验证修复结果： 在调用处补齐 new 后，重新运行单元测试或调试工具，确保实例对象正常持有内部属性，且 instanceof 校验为 true。

图 3：漏写 new 错误的逐步定位与排查逻辑图

四、防范漏写 new 的防御性编程与工程化方案

为了从根本上避免因为疏忽漏写 new 导致的线上故障，现代前端与 Node.js 开发中有四种行之有效的防御方案：

1. 方案一：全面使用 ES6 Class 语法（推荐）

在所有新模块中，坚决弃用传统的 function Name() {} 构造方式，一律采用 ES6 的 class 关键字。Class 会在底层强行要求调用方必须使用 new，否则直接抛错，杜绝一切隐式逻辑故障。

// 推荐：使用 ES6 Class 语法定义业务模型
class Customer {
  constructor(name) {
    this.name = name;
  }
}

// 哪怕疏忽漏写，也能在开发初期立刻被语法检查与引擎报错捕获
const c = new Customer('Bob');

2. 方案二：利用 new.target 实现自适应重定向

如果维护的是老旧代码库或公共库，必须使用函数形式但希望保证调用兼容性，可以使用 ES6 的 new.target 元属性。如果用户正常使用 new 调用，new.target 指向该函数本身；如果作为普通函数调用，new.target 为 undefined。通过这个特性，我们可以做到“即使用户忘记加 new，也能自动补全 new 并返回正确实例”：

function SafeUser(name) {
  // 检查是否通过 new 关键字发起调用
  if (!new.target) {
    // 自动以 new 方式重新调用并返回新实例
    return new SafeUser(name);
  }
  this.name = name;
}

// 此时两种调用方式都能正常工作并获得实例
const u1 = new SafeUser('Tom');
const u2 = SafeUser('Jerry');

console.log(u1 instanceof SafeUser); // true
console.log(u2 instanceof SafeUser); // true
console.log(u2.name); // "Jerry"，没有全局污染，也不报 TypeError

3. 方案三：向后兼容的 instanceof 回退判断

在不支持 ES6 new.target 的远古浏览器或 ES5 纯净环境中，可以使用 instanceof 进行防护：

function LegacyUser(name) {
  // 当以普通函数调用时，this 不会指向 LegacyUser 的实例
  if (!(this instanceof LegacyUser)) {
    return new LegacyUser(name);
  }
  this.name = name;
}

const user = LegacyUser('David'); // 安全创建实例
console.log(user.name); // "David"

4. 方案四：ESLint 静态代码规范校验

通过工程化工具在编码阶段即时提示错误，是避免人工疏漏最省成本的方法。在 ESLint 中开启 new-cap 规则，可以强制要求所有以大写字母开头的函数或类必须配合 new 关键字调用：

// .eslintrc.json 配置规则
{
  "rules": {
    "new-cap": ["error", { "newIsCap": true, "capIsNew": false }]
  }
}

配置生效后，只要在代码中写下 const u = User();，编辑器和 CI 流程就会即刻标红报警，提示 A constructor name should not start with a lowercase letter / Function name must be called with new，在代码合入前将问题完全扼杀。

图 4：现代 JavaScript 规避 new 漏写错误的四种核心策略总结

五、总结

忘记加 new 并不是简单的代码拼写失误，而是会直接改变 JavaScript 函数的调用上下文（Execution Context）：

• 在非严格模式下的传统函数中，它表现为静默的全局变量污染与下游属性读取的 TypeError: Cannot read properties of undefined；
• 在严格模式下的传统函数中，它表现为赋值阶段抛出的 TypeError: Cannot set properties of undefined；
• 在现代 ES6 Class 中，它会受到引擎的直接保护并抛出 TypeError: Class constructor cannot be invoked without 'new'；
• 在内置对象中，可能引发静默的类型偏移（如 Date 退化为普通字符串）。

在日常开发中，优先采用 class 声明、在必要函数内借助 new.target 自适应处理，并配合 ESLint 的 new-cap 静态检查规则，能够从根本上规避此类低级却高危的运行时故障。