javascript中如何实现单例模式_有哪些应用场景？_技术教程

JavaScript单例模式推荐用ES模块导出实例，因其天然单例、安全简洁；闭包封装次之；需用于共享状态、资源独占等场景，避免new调用和测试污染。

JavaScript 中单例模式的典型实现方式

单例模式的核心是「全局唯一实例 + 延迟初始化」，JS 没有原生 class 级访问控制，所以靠闭包或 Symbol + WeakMap 封装私有状态更可靠。最常用且安全的是模块级单例（利用 ES 模块天然单例特性）和函数内闭包封装。

推荐写法：

const Singleton = (function () {
  let instance = null;
  function createInstance() {
    return {
      data: [],
      add(item) { this.data.push(item); },
      getData() { return this.data; }
    };
  }
  return {
    getInstance() {
      if (!instance) {
        instance = createInstance();
      }
      return instance;
    }
  };
})();

调用 Singleton.getInstance() 总返回同一对象。注意：不能用 new Singleton()，否则破坏单例语义。

ES 模块天然单例：最简洁、最安全的实践

现代 JS 项目中，直接导出一个对象实例比手写闭包更自然，也避免了多处引用时意外重建的风险。模块加载器保证整个应用生命周期只执行一次模块代码。

// logger.js
export const Logger = {
  logs: [],
  log(message) {
    this.logs.push(`${new Date().toISOString()} - ${message}`);
  },
  getHistory() {
    return [...this.logs];
  }
};

在任意文件中 import { Logger } from './logger.js'，所有导入都共享同一个 Logger 对象。这是目前生产环境首选方案，无需额外判断逻辑，无竞态风险。

需要防多实例的场景：哪些地方必须用单例？

不是所有“只用一个”的对象都需要刻意实现单例模式；关键看是否涉及**共享状态、资源独占、或跨模块一致性保障**。

WebSocket 连接管理器：多个组件共用同一连接，避免重复握手和资源浪费
全局配置中心（如 ConfigService）：配置应统一加载、不可被局部覆盖
缓存容器（如 MemoryCache）：不同业务模块读写同一内存空间，需避免各自维护副本
日志上报器（含节流/批处理逻辑）：多个调用点必须聚合到同一个发送队列

反例：一个纯工具函数集合（如 StringUtils）不需要单例——它无状态，导出函数即可。

容易踩的坑：new 实例、构造函数暴露、测试隔离失败

常见错误是把单例写成可 new 的类，导致使用者误用：

class BadSingleton {
  constructor() {
    this.id = Math.random(); // 每次 new 都不同！
  }
}
// ❌ 错误用法
const a = new BadSingleton();
const b = new BadSingleton(); // a !== b

正确做法是让构造函数私有化（JS 中只能靠约定或 WeakMap 拦截），或干脆不暴露构造函数。

另一个问题是单元测试时单例状态残留：上一个 test 修改了 Logger.logs，下一个 test 读到脏数据。解决方式是在每个 test 后重置（afterEach(() => { Logger.logs.length = 0; })）或使用依赖注入替代直接 import 单例模块。

真正难的不是写单例，而是判断「这个对象是否真的需要全局唯一性」——多数时候，模块导出 + 显式 import 已足够；只有当状态耦合深、生命周期复杂、或需跨 bundle 共享时，才值得引入显式单例封装逻辑。