JavaScript单例模式怎么实现？你用过吗

JavaScript中的单例模式并非语言原生支持，而是依赖开发者通过闭包+IIFE或ES6 class+静态属性等手段主动控制实例唯一性，核心在于确保全局仅有一个可复用的实例；但实践中需警惕滥用——它不等于全局状态容器，不当使用易导致耦合、测试困难、跨环境污染（如SSR或微前端），真正关键的不是实现技巧，而是厘清“为何必须唯一”：明确生命周期、共享边界与销毁时机，否则再“规范”的单例反而成为调试噩梦。

单例模式在 JavaScript 中不是靠语言机制强制实现的，而是靠开发者主动控制实例创建逻辑——只要确保全局只存在一个实例，并能重复获取它，就算达成目标。

用闭包 + 模块模式封装私有实例

这是最常用、也最符合 JS 特性的写法。利用立即执行函数（IIFE）和闭包变量，把实例“藏”在作用域里，外部无法篡改。

• instance 变量不会暴露到全局，避免被意外覆盖
• 构造函数可以带参数，但首次调用后参数不再生效（除非你主动重置）
• 适合需要延迟初始化、或依赖异步准备工作的场景

const Singleton = (function() {
  let instance = null;

  function createInstance() {
    return {
      data: Math.random(),
      log() { console.log('Singleton:', this.data); }
    };
  }

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

// 使用
const a = Singleton.getInstance();
const b = Singleton.getInstance();
console.log(a === b); // true

用 ES6 class + 静态属性实现

更接近传统 OOP 写法，语义清晰，但要注意 instance 是静态属性，仍需手动检查是否已存在。

• 不能直接 new 类来绕过单例逻辑——必须通过 getInstance()
• 如果类有继承需求，需额外处理子类的 instance 独立性
• 若构造函数抛错，instance 可能为 null 或未定义，建议加 try/catch

class Logger {
  constructor() {
    if (Logger.instance) {
      return Logger.instance;
    }
    this.id = Date.now();
    Logger.instance = this;
  }

  static getInstance() {
    if (!Logger.instance) {
      Logger.instance = new Logger();
    }
    return Logger.instance;
  }

  log(msg) {
    console.log(`[${this.id}] ${msg}`);
  }
}

// 使用
const l1 = Logger.getInstance();
const l2 = Logger.getInstance();
console.log(l1 === l2); // true

注意：new 操作符和构造函数陷阱

JS 的 new 本身不阻止多次实例化。如果你允许用户直接 new Singleton()，那单例就失效了。

• 不要只靠 if (instance) return instance 放在构造函数里——new 会忽略 return 的非对象值
• 若返回原始值（如 return 42），new 仍返回新对象；只有返回对象才可能拦截
• 真正安全的做法是：禁止直接 new，只暴露工厂方法（如 getInstance），或用 Symbol 私有标识做运行时校验

真实项目中单例常被误用的地方

单例不是“全局状态”的代名词。比如把用户配置、API token、主题设置等全塞进一个单例里，会导致耦合、难以测试、无法多实例隔离（比如同时管理多个账号）。

• 优先考虑依赖注入（DI）或模块顶层变量，比手写单例更易维护
• 浏览器扩展、微前端、SSR 环境下，单例容易跨上下文污染（比如服务端渲染时共享了客户端实例）
• 如果需要“每个 tab 独立单例”，得结合 window.name 或 localStorage 做命名空间隔离

单例的关键不在“怎么写”，而在“为什么必须唯一”。没想清楚生命周期、共享边界和销毁时机，代码越“规范”越难调试。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~