JavaScript 单例模式三种实现对比：闭包、Class 与 Module 怎么选

一、单例模式的核心机制与运行流程

在前端开发中，诸如全局状态管理器（如 Redux store / Pinia）、全局配置管理中心、全局弹窗控制器、WebSocket 连接池或日志埋点管理器，往往要求系统各处共享同一份状态与上下文。如果每次使用都实例化一个新对象，不仅造成内存浪费，还会导致多处状态不同步、连接被重复建立等严重缺陷。

单例模式的核心流程可以简化为一个“拦截与复用”的闭环机制：当调用方发起获取实例的请求时，程序首先检查内存中是否已有创建好的现存实例。如果已经存在，直接返回现有引用；如果尚未创建，则执行初始化逻辑，将新建的对象引用缓存至特定受保护的存储区域，再将该引用返回。

二、实现方案一：基于闭包（Closure）与 IIFE

闭包是 ECMAScript 最经典也最底层的数据隐藏机制。通过立即调用函数表达式（IIFE），在外部函数作用域内声明一个局部变量用来存储实例，并返回一个闭包函数。外部环境无法直接访问或覆写这个私有变量，只能通过暴露出来的访问器来获取。

1. 完整实现代码

// loggerSingletonClosure.js
const LoggerSingleton = (function () {
  // 驻留在函数闭包堆中的私有实例引用，外界完全无法访问
  let instance = null;

  function createInstance() {
    return {
      appName: 'MonitoringApp',
      logs: [],
      log(message) {
        const timestamp = new Date().toISOString();
        this.logs.push(`[${timestamp}] ${message}`);
      },
      getLogs() {
        return [...this.logs];
      }
    };
  }

  return {
    getInstance() {
      if (!instance) {
        instance = createInstance();
      }
      return instance;
    }
  };
})();

// 验证执行结果
const clientA = LoggerSingleton.getInstance();
const clientB = LoggerSingleton.getInstance();

clientA.log('User login: admin');
console.log(clientB.getLogs().length); // 示例输出: 1
console.log(clientA === clientB);     // 示例输出: true

2. 闭包方案的优势与局限

• 绝对私有性：变量 instance 完全处于闭包函数体中，外部没有任何原生手段可以直接修改该引用，安全性最高。
• 天然支持惰性初始化：只有在真正调用 getInstance() 时才执行 createInstance()，避免了应用启动时的无效性能消耗。
• 缺点：语法结构较为繁琐，未能利用现代类的语法糖；另外，如果后续需要为该对象实现类继承、多态扩展或 TypeScript 类型推断，写法较为生硬。

三、实现方案二：基于 ES6 Class 与静态私有属性

随着 ECMAScript 标准演进，类（Class）成为主流面向对象开发规范。现代 JavaScript（ES2022+）提供了原生的类私有字段（以 # 开头），使得我们可以在类级别完美维护单例引用。

1. 静态访问器结合私有字段（推荐范式）

在类内部声明 static #instance，同时在 constructor 中加入防御检查，禁止外部直接调用 new 产生多个实例：

// DatabasePool.js
class DatabasePool {
  // ES2022 原生私有静态字段
  static #instance = null;

  constructor(connectionString) {
    if (DatabasePool.#instance) {
      throw new Error('请使用 DatabasePool.getInstance() 获取单例，禁止直接 new');
    }
    this.connectionString = connectionString;
    this.connected = true;
  }

  static getInstance(connectionString = 'mongodb://localhost:27017') {
    if (!DatabasePool.#instance) {
      DatabasePool.#instance = new DatabasePool(connectionString);
    }
    return DatabasePool.#instance;
  }

  query(sql) {
    if (!this.connected) throw new Error('连接未就绪');
    return `执行查询: ${sql} 在连接: ${this.connectionString}`;
  }
}

// 验证执行
const db1 = DatabasePool.getInstance();
const db2 = DatabasePool.getInstance();

console.log(db1 === db2); // 示例输出: true

try {
  new DatabasePool('localhost:3306');
} catch (err) {
  console.log(err.message); // 示例输出: 请使用 DatabasePool.getInstance() 获取单例，禁止直接 new
}

2. Class 方案的优势与局限

• 语义标准清晰：符合标准 OOP 思想，便于使用 TypeScript 定义类型注解和接口继承。
• 生命周期控制明确：可通过 static resetInstance() 在自动化测试中重置状态，测试友好度高于匿名闭包。
• 缺点：需要编写较多样板代码（防御检查、静态方法声明）；如果不使用构建工具转译，在极老旧浏览器环境下需依靠 Babel 转换 #private 语法。

四、实现方案三：基于 ES Module 原生缓存机制

在如今 Vite、Webpack、Rollup 统治的前端工程化项目中，ES Module（ESM）已经成为 JavaScript 的事实标准。ES 规范明确规定：模块在第一次被 import 时会被执行求值，求值完成后该模块的作用域环境与导出项会被引擎完全缓存在模块注册表（Module Registry）中。

1. 完整实现代码

// apiClient.js
class ApiClient {
  constructor() {
    this.baseURL = 'https://api.example.com/v1';
    this.token = null;
  }

  setToken(token) {
    this.token = token;
  }

  request(endpoint) {
    return `Request to ${this.baseURL}${endpoint} with token: ${this.token}`;
  }
}

// 实例化并在模块层面导出
export const apiClient = new ApiClient();

// userProfile.js
import { apiClient } from './apiClient.js';
apiClient.setToken('auth-xyz-987');

// authService.js
import { apiClient } from './apiClient.js';
console.log(apiClient.request('/users/me'));
// 示例输出: Request to https://api.example.com/v1/users/me with token: auth-xyz-987

无论在 userProfile.js 还是 authService.js 中引入，得到的 apiClient 都指向同一个堆内存地址。模块本身的独立作用域天然隔绝了外部随意重绑定的可能。

五、深度技术差异与潜在陷阱分析

表面上看三者都能实现“单例”效果，但在真实工程落地时，它们的表现存在几个关键分水岭：

1. 懒加载（Lazy Evaluation）与启动开销

如果单例对象的创建逻辑包含繁重的初始化操作（如读取并解析大型配置、预分配海量内存池），过早创建会导致应用首屏启动出现肉眼可见的白屏或卡顿。

• 闭包与 Class：具备天然的懒加载能力。只有首次调用 getInstance() 时才会进入初始化逻辑；如果不被调用，不会产生任何实例化开销。
• 直接导出的 Module：属于即时求值（Eager Loading）。当任意文件只要 import './apiClient.js'，即使并未立即使用其方法，模块根作用域也会立刻执行 new ApiClient()。如果需要懒加载，模块方案必须结合动态引入 import('./apiClient.js')，或者在模块内导出返回单例的函数包装器。

2. 单元测试与状态隔离污染

单例模式在测试阶段容易引起恶名昭彰的“测试用例间状态污染”：测试用例 A 修改了单例的内部状态，紧接着运行的测试用例 B 如果预期该单例处于初始状态，就会引发莫名其妙的测试断言失败。

• 闭包方案：闭包内的 instance 完全封闭。如果一开始没在暴露对象中保留专门重置的函数（如 _resetForTesting()），测试框架极难清空其状态。
• Class 方案：由于是静态方法结构，非常方便在测试辅助工具中添加 static reset() 清空私有字段，测试适配最灵活。
• ES Module 方案：在 Vitest 或 Jest 中，需要借助 vi.resetModules() 或 jest.resetModules() 清空模块缓存，使下次 import 重新执行模块代码，需要测试运行器的针对性配合。

3. 服务端渲染（SSR）与多包路径陷阱

六、实战选型指南：我该怎么选？

面对具体业务场景，建议通过以下决策路径快速确定最合理的单例方案：

七、总结

单例模式并不局限于某一种特定的语法模板，其精髓在于建立一个可控的生命周期，避免重复创建和状态错位。在日常技术选型中：

1. 常规业务开发：直接依靠 export const service = new Service()，借助构建器与 JavaScript 引擎原生的模块单例机制，无需为经典设计模式编写冗余的代码套路。
2. 架构层与框架工具库：采用 ES2022 static #instance 的 Class 静态方法，具备严密的调用防御拦截，兼顾面向对象的规范性与单元测试的灵活度。
3. 独立脚本与 SDK 封装：利用闭包与 IIFE 进行彻底的词法边界封闭，在无外部模块系统的环境中确保私有变量绝对不泄露到全局空间。