JavaScript常见设计模式及单例实现方法

JavaScript中真正可靠且易于落地的单例模式，核心在于利用模块作用域（ES模块默认导出）或闭包缓存来天然保证实例唯一性，而非依赖构造函数拦截或`new`关键字——因为后者在跨模块、多chunk、微前端等现代工程场景下极易导致实例分裂；文章直击痛点，揭示了为何`getInstance()`应成为唯一入口、`new`必须被禁止，并通过轻量模块导出、延迟初始化工厂函数、谨慎使用的Class写法三种方案，给出兼顾简洁性、安全性与工程健壮性的实践路径，同时提醒开发者：单例真正的挑战不在实现，而在它对可测试性、依赖透明性和运行时隔离性带来的隐性代价。

JavaScript 中能稳定落地的单例模式，核心就一条：**用闭包或模块作用域控制实例唯一性，别依赖 new 关键字本身**。直接写 class Singleton 然后靠构造函数拦截，多数场景反而埋坑。

为什么不能靠 constructor 拦截来实现单例？

很多人第一反应是“在构造函数里判断 this._instance”，但问题在于：new 每次都会创建新对象，this 不是共享的；而静态属性又可能被外部篡改或跨模块失效（尤其在 ESM 环境下）。

• Singleton.getInstance() 是可靠入口，new Singleton() 应该被禁止或抛错
• ESM 的模块缓存机制天然支持单例，比手动管理 _instance 更轻量、更安全
• 如果用了打包工具（如 Webpack/Vite），多次 import 同一模块，仍指向同一模块实例 —— 这才是 JS 单例最自然的底座

最简可行的单例：ES 模块 + 默认导出

不写 class，不搞私有字段，靠模块顶层作用域天然单例。适用于配置、日志器、状态管理器等轻量全局服务。

const logger = {
  logs: [],
  log(msg) {
    this.logs.push(`[${new Date().toISOString()}] ${msg}`);
    console.log(msg);
  }
};

export default logger;

所有地方 import logger from './logger.js' 拿到的都是同一个对象引用。无需额外逻辑，无兼容性问题，无内存泄漏风险。

需要延迟初始化时：工厂函数 + 闭包缓存

当单例依赖异步资源（如 API 初始化）、或创建开销大、且不希望模块加载时就执行，用闭包缓存更可控。

let instance = null;

function createDatabaseConnection() {
  // 模拟耗时初始化
  return { query(sql) { return `result from ${sql}`; } };
}

export function getDB() {
  if (!instance) {
    instance = createDatabaseConnection();
  }
  return instance;
}

• 调用 getDB() 多次，返回同一对象
• instance 在模块作用域内，外部无法直接修改
• 注意：若 createDatabaseConnection 抛错，当前实现会重复执行 —— 生产中应加错误标记（如 instance = { error: err }）避免无限重试

Class 写法的单例：只暴露静态方法，禁用 new

如果团队强依赖 class 语法，必须确保构造不可见。常见错误是把 getInstance 写成实例方法，或允许 new 成功。

class ConfigManager {
  constructor() {
    if (ConfigManager.instance) {
      throw new Error('Use ConfigManager.getInstance() instead of new');
    }
    this.data = {};
  }

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

  set(key, value) {
    this.data[key] = value;
  }
}

// 静态属性在模块级有效，但需注意：Webpack 的 scope hoisting 可能导致多个 chunk 中的 ConfigManager.instance 不共享
export default ConfigManager;

真正麻烦的点不在写法，而在多入口、微前端、动态 import() 场景下，ConfigManager.instance 可能出现多个副本 —— 这时候模块级单例（前两种）反而更稳。

单例最难的不是“怎么写”，而是“在哪用”：它会让测试变难、隐藏依赖、阻碍并发隔离。真要用，优先选模块默认导出；非得 class，就别让 new 成功；所有方案都要警惕跨 chunk / 跨沙箱环境的实例分裂。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaScript常见设计模式及单例实现方法》文章吧，也可关注golang学习网公众号了解相关技术文章。