JS构造器忘记加new会怎么：this指向错误与修复方法

在 JavaScript 中，如果将构造函数当作普通函数直接调用而遗漏了 new 关键字，引擎将不会为其开辟独立的内存对象，函数体内部的 this 不会绑定到新实例，而会指向全局宿主对象（非严格模式下造成全局变量污染）或保持为 undefined（严格模式下直接抛出 TypeError）。同时，函数由于缺乏显式返回值将默认产出 undefined，导致调用方接收到的并非预期实例。解决此问题可通过经典 instanceof 原型自检重定向、ES6 new.target 元属性判定，或直接在项目中使用 ES6 class 语法从语言层面杜绝此类错误调用。

一、构造函数不加 new 时究竟发生了什么？

要透彻理解漏加 new 带来的后果，首先需要看清 new 操作符在幕后默默为开发者承担的工作。通常情况下，我们编写的构造函数本质上只是一个常规的 JavaScript 函数，本身并没有任何特殊的内存特权。

当执行 new Person("Alice") 时，JavaScript 引擎会严格按顺序完成以下四项核心操作：

1. 开辟新对象：在内存中分配一块全新的空间，创建一个空对象 {}。
2. 连接原型链：将这个新对象的内部隐藏属性 [[Prototype]]（在浏览器中体现为 __proto__）指向构造函数的 prototype 对象。
3. 绑定 this 并执行：将函数执行上下文中的 this 绑定到刚刚创建的这个新对象上，并传入参数开始执行函数体代码。
4. 决议返回值：检查函数执行的返回结果。如果函数返回了一个非空对象，则最终产出该对象；若无显式返回或返回的是原始类型，则强制将第一步创建的实例对象作为结果产出。

一旦我们在调用时遗漏了 new（例如直接写 Person("Alice")），上述第 1、2、4 步全部不复存在。调用表达式退化为一次极其普通的值传递函数调用，函数的执行完全遵循常规函数上下文的推导逻辑。

二、不同运行模式下的故障表现与连锁隐患

遗漏 new 后代码会产生何种外在表现，直接取决于该代码片段运行在非严格模式（Sloppy Mode）还是严格模式（Strict Mode）下。这两种环境下的破坏力截然不同，其中非严格模式下的静默故障往往具有更强的欺骗性。

1. 非严格模式：静默污染全局命名空间

在没有声明 'use strict' 的传统脚本中，独立调用的普通函数其 this 会自动回退（Fallback）绑定到全局宿主对象。在浏览器环境中，全局对象是 window；在 Node.js 中是 global；在现代多端规范中则是 globalThis。

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

// 遗漏 new 关键字
const alice = User("Alice", "Admin");

console.log(alice);        // 示例输出: undefined
console.log(window.name);  // 示例输出: "Alice" (已破坏 window 原有属性！)
console.log(window.role);  // 示例输出: "Admin" (无意间向全局暴露了变量)

这种故障极其恶劣，因为它不会触发任何报错。开发者很难立刻察觉到赋值已失败，特别是当属性名恰好与原生全局属性重名时（例如 window.name 是浏览器的内置窗体名称属性，接收字符串值），构造函数无意间的赋值会直接改写浏览器的运行态属性，诱发难以排查的幽灵 Bug。

2. 严格模式：即时中断与 TypeError 抛出

如果脚本顶部开启了 'use strict'，或者代码处于 ES6 模块（ES Module）内部，普通函数被独立调用时，this 将严格保持为 undefined，不会自动转移到全局。

"use strict";

function User(name) {
  this.name = name; // TypeError: Cannot set property 'name' of undefined
}

User("Alice");

此时，引擎尝试对 undefined 执行属性写入操作，立即抛出运行时异常并终止执行栈。虽然程序发生了崩溃，但这种“快速失败（Fail Fast）”机制使得错误能够在第一现场被捕获，远比非严格模式下的暗中破坏更容易调试。

3. 返回值丢失导致的二度雪崩

不管是哪种模式，构造函数设计之初通常不会编写 return 语句，因为它们依赖 new 自动返回实例。由于普通函数在没有显式 return 时默认返回 undefined，接收调用结果的变量实际拿到了空值：

const bob = User("Bob"); // 得到 undefined

// 稍后在业务逻辑中调用实例方法
bob.greet(); // Uncaught TypeError: Cannot read properties of undefined (reading 'greet')

此时真正的调用栈已经过去很久，报错点却出现在完全无关的下游业务代码中，进一步增加了代码维护的排查成本。

三、常见误区与深层辨析

在排查和学习这个问题时，开发者之间流传着一些看似合理、但深入推敲后存在漏洞的经验说法。对这些做法进行理性辨析，有助于加深对语言特性的理解。

四、四种实用修复与防护方法

为了防止由于手误或团队成员疏忽导致遗漏 new，JavaScript 在语言演进过程中提供了从运行时防御到静态管制的完整工具链。

方法 1：基于 instanceof 的经典自适应实例化（ES5 兼容）

这是在 ES6 出现前主流开源类库（如早期的 jQuery）广泛采用的兼容性极高的方案。在函数入口处检测当前的 this 是否由当前构造函数所生成；如果不是，则主动调用 new 并返回：

function Product(id, name) {
  // 校验当前执行上下文的 this 是否是 Product 的实例
  if (!(this instanceof Product)) {
    return new Product(id, name);
  }
  
  this.id = id;
  this.name = name;
}

// 无论加不加 new，均能正常工作
const p1 = new Product(101, "键盘"); // 正常走常规构造
const p2 = Product(102, "鼠标");     // 自动拦截并内部执行 new

console.log(p1 instanceof Product); // true
console.log(p2 instanceof Product); // true

该方案能够良好向下兼容到 ES3/ES5 环境，并且对调用端完全透明，既支持传统 OOP 的 new 语法，也支持平滑的函数式调用。

方法 2：基于 ES6 new.target 元属性的精准防护

ES6 规范引入了专属的元属性 new.target。当函数通过 new 关键字调用时，new.target 的值精准指向该函数本身；若是作为普通函数调用，new.target 的值则恒为 undefined。

function Widget(width, height) {
  // 检查是否通过 new 触发
  if (!new.target) {
    // 策略 A：平滑自愈（自动补 new）
    return new Widget(width, height);
    
    // 或者策略 B：严格拦截（抛出规范错误）
    // throw new TypeError("Widget 构造函数必须使用 'new' 进行实例化！");
  }
  
  this.width = width;
  this.height = height;
}

const w = Widget(800, 600); // 即使漏写 new，依然安全返回新实例

与 instanceof 相比，new.target 不依赖原型链爬寻，不会被 call/apply 虚假的 this 蒙蔽，更不会因跨 <iframe> 环境而产生判断失误，是 ES6 环境下函数构造器的最佳选择。

方法 3：升级为 ES6 class 语法（现代开发首选）

现代 JavaScript 提供了原生的 class 关键字。根据 ECMAScript 规范定义，类构造器在底层拥有内置的 [[IsClassConstructor]] 内部槽位，语言标准明确禁止直接将其作为普通函数执行：

class Account {
  constructor(owner, balance) {
    this.owner = owner;
    this.balance = balance;
  }
}

// 正确调用
const acc = new Account("Alice", 5000);

// 遗漏 new 调用
Account("Bob", 3000);
// 终端报错: Uncaught TypeError: Class constructor Account cannot be invoked without 'new'

采用 class 定义时，开发者无需编写任何样板检查代码，JavaScript 运行时会自动提供顶级的防护支持。这是现代项目最为推荐的做法。

方法 4：利用 ESLint 规则提前做静态拦截

除了代码层面的运行时防护，在工程化构建流程中引入静态分析工具，可以在编写代码阶段或提交 Git 时即时发现问题。

// .eslintrc.json 配置规则
{
  "rules": {
    // 强制构造函数首字母大写，且大写函数必须使用 new 调用
    "new-cap": ["error", { "newIsCap": true, "capIsNew": true }]
  }
}

开启该规则后，如果开发者直接书写 const u = User("Alice");，IDE 和 CI 构建管道将直接标红并报错 A constructor name should not start with a lowercase letter or Function 'User' is not invoked with 'new'，将风险完全消灭在发布之前。

五、实战方案选型与总结

在实际工程开发与旧系统维护中，不同的场景应对应不同的策略。下表汇总了各种方案的核心考量：

解决方案	适用环境	调用行为结果	主要优势与考量
ES6 class 语法	现代项目 / ES6+	漏 new 时直接抛出 TypeError	原生规范级约束，语义明确，无须额外防御代码
new.target 校验	ES6+ 函数构造器	可自由配置：自愈补 new 或抛错	判定 100% 精确，不受 call/apply 及跨 Realm 影响
instanceof 重定向	遗留系统 / ES5 兼容库	自动补偿 new，安全返回实例	全面向下兼容，支持平滑的函数式免 new 调用
ESLint 静态规则	所有前端构建工程	代码编译/保存阶段拦截报错	防患于未然，零运行时性能损耗

完整的落地排查与决策路径可参照以下导图：