JavaScript new绑定实现单例构造函数策略

在 Ja vaScript 中实现单例模式，本质上是一场与 new 绑定默认行为的博弈。每次调用构造函数时，引擎都会老老实实地新建一个对象，而单例的诉求恰恰相反——整个生命周期只允许一个实例存在。因此，核心任务就是想办法“骗过” new，让它返回你手里已有的那个实例，而不是再浪费一个新对象。

new 绑定本身不支持单例——它每次调用都老老实实创建新对象。所以实现单例构造函数，本质是绕过或拦截 new 绑定的默认行为，在构造阶段主动控制实例的生成逻辑。

核心思路：拦截 new 调用，复用已有实例

Ja vaScript 没有语言级别的单例语法，必须靠代码逻辑来干预。关键不是去修改 new，而是让构造函数在被 new 调用时，不真正新建对象，而是返回已经存在的那个。

• 不能依赖 new 绑定自动创建对象，要主动判断是否已有实例
• 实例需私有保存（如闭包变量、静态属性），避免外部篡改
• 确保每次 new 都返回同一引用，且 this 在构造函数体内仍指向该实例（否则初始化逻辑会失效）

常用实现方式

闭包 + 构造函数封装（推荐）

用 IIFE 封装私有 instance 变量，构造函数内部不直接暴露 new 行为。定义一个工厂函数，内部维护 instance，首次调用时 new 构造函数，后续直接返回 instance。构造函数本身可以保持原样，不修改其逻辑，解耦清晰。

例如：

const createDB = (() => {
  let instance;
  return () => {
    if (!instance) instance = new Database();
    return instance;
  };
})();

Proxy 拦截 construct（ES6+）

重写 new 的行为，把 new MyClass() 重定向到单例逻辑。用 Proxy 包裹类，捕获 construct 操作，在其中做实例存在性判断。注意 Proxy 返回的必须是对象，且需用 Reflect.construct 正确调用原构造逻辑（首次）。缺点：兼容性略低，调试稍复杂，但语义最接近“改造 new”。

构造函数内自检（简单但有风险）

在构造函数开头检查 new.target 或 this 是否已存在同类实例。利用 new.target 判断是否被 new 调用；或通过 this.constructor === MyClass 且 this 已初始化来识别重复。常见陷阱：若直接 return 已有实例，new 绑定会忽略该返回（除非返回对象），但 this 已绑定到新对象，造成状态错乱。更稳妥的做法是：首次 new 后把实例挂到构造函数上（如 MyClass.instance），后续 new 时手动将 this 属性复制过去，再返回该 instance。

为什么不能靠 new 绑定自身实现单例

因为 new 绑定的四步流程是引擎强制执行的：创建空对象 → 设置原型 → this 绑定 → 执行函数体 → 返回。这个过程不可跳过，也无法在绑定发生前阻止。你无法让 new 不创建对象，只能让它创建后“弃用”，转而返回另一个对象。

• 箭头函数不能 new，普通函数一旦被 new，this 必然指向新对象——这是 new 绑定的底层刚性规则
• 所以单例不是“让 new 不起作用”，而是“让 new 的结果被覆盖”
• 返回的对象若为非 null 对象，new 表达式就直接返回它，原新对象被丢弃；这是唯一能绕过 new 默认返回的出口

注意事项

单例不是万能方案，尤其在模块热更新、多实例测试、SSR 等场景容易出问题。

• 避免全局污染：实例应封装在模块作用域内，而非 window 或 globalThis
• 考虑初始化参数：首次调用传参有效，后续调用参数应被忽略或报错提示
• 警惕原型污染：如果单例实例被意外修改原型链，可能影响所有使用方
• 测试友好性：建议提供 reset 方法（仅开发环境），便于单元测试隔离