JavaScript 单例模式基础实现：闭包与 IIFE 写法详解

一、为什么对象字面量不等于真正的单例模式

在 JavaScript 中，许多初学者经常会问：直接声明一个对象字面量 const config = { ... }，它在内存中不也是唯一的全局对象吗？为什么还需要费尽周折地使用闭包与设计模式？

尽管对象字面量在语义上确实具备“全局唯一引用”的外在特征，但在严格的软件工程与面向对象设计中，它无法替代真正的单例模式，主要原因在于其存在三项不可忽视的缺陷：

• 缺乏私有状态与封装能力：对象字面量上的所有属性与方法均为对外公开（Public）暴露，外部任意模块均可直接修改甚至清空其内部状态，无法实现私有属性的隐藏与保护。
• 无法推迟实例化（无 Lazy Loading）：对象字面量在脚本加载与语法分析阶段即完成内存分配。如果该对象需要执行高开销的计算逻辑、建立 WebSocket 网络长连接，或者读取复杂本地配置，过早实例化会严重拖慢应用的冷启动性能。
• 抗篡改与防覆盖能力脆弱：直接暴露在全局或模块根作用域的变量名极易被误赋值（例如误写 config = null），从而导致全局引用链直接断裂。

而立即执行函数表达式（IIFE）与闭包（Closure）正是解决上述短板的黄金搭档。IIFE 在脚本运行瞬间提供独立且封闭的函数词法作用域，切断外部的直接访问路径；闭包则将该作用域内的缓存变量长期驻留在内存中，并仅通过受控的返回函数对外提供读写通道。

二、基础经典实现：IIFE 结合闭包的懒汉式单例

所谓的“懒汉式（Lazy Initialization）”，是指单例对象并不会在 IIFE 执行时立即生成，而是推迟到外部代码首次显式调用获取方法时才真正执行构造流程。在后续的所有调用中，直接返回首次创建并缓存好的实例引用。

1. 编写步骤拆解

1. 第一步：声明私有缓存变量。在 IIFE 内部定义 let instance = null;。由于 instance 处于函数私有作用域，外部无法直接读取或改写它。
2. 第二步：定义私有构造与初始化逻辑。编写专门负责实例化的私有函数 init()，内部封装核心配置、私有属性以及业务方法。
3. 第三步：返回携带访问句柄的闭包对象。IIFE 返回一个字面量对象，内部暴露 getInstance() 方法。当 instance 为空时触发 init() 并完成赋值，否则直接返回该引用。

2. 完整代码示例

// 经典闭包与 IIFE 懒汉式单例实现
const DatabaseConnector = (function () {
  // 1. 私有缓存变量，受 IIFE 词法作用域保护
  let instance = null;

  // 2. 私有初始化逻辑，封装内部状态
  function init(config) {
    // 私有字段，外部完全不可见
    const host = config?.host || 'localhost';
    const port = config?.port || 3306;
    let queryCount = 0;

    // 返回对外提供的业务操作接口
    return {
      getHost: function () {
        return host;
      },
      getPort: function () {
        return port;
      },
      getQueryCount: function () {
        return queryCount;
      },
      query: function (sql) {
        queryCount++;
        return `[${host}:${port}] 执行查询: ${sql} (累计: ${queryCount})`;
      }
    };
  }

  // 3. 对外导出访问入口，形成闭包引用
  return {
    getInstance: function (config) {
      if (!instance) {
        instance = init(config);
      }
      return instance;
    }
  };
})();

3. 调用与内存一致性验证

我们可以通过分别调用 getInstance()，传入不同参数，并检查两个返回变量的引用地址与状态同步表现：

// 第一次调用：执行 init()，初始化为 192.168.1.100:5432
const clientA = DatabaseConnector.getInstance({ host: '192.168.1.100', port: 5432 });
console.log(clientA.query('SELECT * FROM users')); 
// 输出: [192.168.1.100:5432] 执行查询: SELECT * FROM users (累计: 1)

// 第二次调用：传入不同配置，测试是否被忽略并直接复用缓存
const clientB = DatabaseConnector.getInstance({ host: '10.0.0.1', port: 3306 });
console.log(clientB.query('SELECT * FROM logs')); 
// 输出: [192.168.1.100:5432] 执行查询: SELECT * FROM logs (累计: 2)

// 关键检验：全等判断
console.log(clientA === clientB); // 输出: true

上述验证清晰地展示了单例的核心行为：clientB 并没有因为传入新的配置而重新执行 init()，而是直接拿到了 clientA 所引用的同一内存地址，内部的 queryCount 计数器在两次调用间连贯累加，全等比较返回 true。

三、进阶演进：透明单例（Transparent Singleton）写法

在上面的经典写法中，调用方必须显式知道并调用 DatabaseConnector.getInstance()。但在某些面向对象编程风格的代码库中，开发者希望类的使用者像实例化普通类一样，直接使用 new Singleton() 关键字，而类的内部能够自适应保证实例唯一性。这种让调用方对单例机制“无感知”的设计，被称为透明单例。

在 JavaScript 中实现透明单例的核心秘密在于：如果构造函数显式返回一个对象，那么 new 表达式的执行结果将直接使用该返回对象，而不是新创建的 this 绑定。

透明单例完整实现

// 透明单例实现：使用者直接使用 new 操作符
const WindowManager = (function () {
  let instance = null;

  // 构造函数
  function WindowManager(title, width, height) {
    // 若闭包中已存在单例实例，利用构造函数返回值重定向特性直接返回旧实例
    if (instance) {
      return instance;
    }

    // 首次实例化：初始化实例属性
    this.title = title || 'Default Window';
    this.width = width || 800;
    this.height = height || 600;

    // 缓存当前新创建的 this
    instance = this;
  }

  // 在原型链上拓展公共方法
  WindowManager.prototype.render = function () {
    return `渲染窗口: ${this.title} [${this.width}x${this.height}]`;
  };

  return WindowManager;
})();

验证透明调用效果：

// 无论调用多少次 new，返回的对象引用恒定一致
const win1 = new WindowManager('控制台主界面', 1024, 768);
const win2 = new WindowManager('浮动窗口', 300, 200);

console.log(win1.render()); // "渲染窗口: 控制台主界面 [1024x768]"
console.log(win2.render()); // "渲染窗口: 控制台主界面 [1024x768]"
console.log(win1 === win2); // 输出: true

四、实战场景：Web 全局模态弹窗管理器

在现代 Web 应用中，全局模态弹窗（Modal / Dialog）是单例模式最典型的应用场景之一。若每次触发通知提示都重新通过 document.createElement 构建 DOM，会导致以下问题：

• 频繁触发浏览器的 DOM 回流（Reflow）与重绘（Repaint），消耗渲染性能；
• 多个弹窗未统筹管理，容易发生多层遮罩错位堆叠、页面焦点抢占与事件穿透；
• 难以统一维护弹窗的开启、关闭过渡动画与单一激活状态。

通过闭包结合 IIFE，我们可以确保整个应用生命周期中只会在初次唤起时生成唯一的弹窗 DOM 结构，后续所有模块共享该实例：

// 全局模态弹窗单例管理器
const GlobalModal = (function () {
  let modalInstance = null;

  function createModalDOM() {
    // 1. 创建遮罩层与外层容器
    const overlay = document.createElement('div');
    overlay.className = 'global-modal-overlay';
    overlay.style.cssText = `
      position: fixed;
      top: 0; left: 0; width: 100%; height: 100%;
      background: rgba(44, 62, 80, 0.45);
      display: none;
      align-items: center;
      justify-content: center;
      z-index: 9999;
    `;

    // 2. 创建弹窗卡片本体
    const card = document.createElement('div');
    card.style.cssText = `
      background: #FFFFFF;
      padding: 24px;
      border-radius: 8px;
      min-width: 320px;
      box-shadow: 0 10px 30px rgba(0, 0, 0, 0.15);
    `;

    const messageText = document.createElement('p');
    messageText.style.cssText = 'color: #2C3E50; font-size: 15px; margin-bottom: 20px;';

    const confirmButton = document.createElement('button');
    confirmButton.innerText = '确认';
    confirmButton.style.cssText = `
      background: #438A80;
      color: #FFFFFF;
      border: none;
      padding: 8px 18px;
      border-radius: 4px;
      cursor: pointer;
      float: right;
    `;

    card.appendChild(messageText);
    card.appendChild(confirmButton);
    overlay.appendChild(card);
    document.body.appendChild(overlay);

    confirmButton.addEventListener('click', function () {
      overlay.style.display = 'none';
    });

    // 3. 返回包含受控操作方法的单例对象
    return {
      show: function (msg) {
        messageText.innerText = msg;
        overlay.style.display = 'flex';
      },
      hide: function () {
        overlay.style.display = 'none';
      },
      getOverlayNode: function () {
        return overlay;
      }
    };
  }

  return {
    getInstance: function () {
      if (!modalInstance) {
        modalInstance = createModalDOM();
      }
      return modalInstance;
    }
  };
})();

使用方式极度简洁：任何业务组件仅需调用 GlobalModal.getInstance().show('操作成功！')，即可复用底层的单一 DOM 节点，避免无节制的节点增删开销。

五、常见问题与工程避坑指南

单例模式虽然结构简单，但在长期维护的大型前端项目中，若不注意生命周期与环境隔离，容易引发难以察觉的隐患。以下总结三个核心避坑点：

1. 闭包常驻内存与显式销毁机制

闭包会使 instance 变量逃逸出垃圾回收器的默认标记范围。如果单例对象内部挂载了巨型数组、图片缓存、或是绑定了全局的 window.addEventListener，这些资源在页面卸载前将无法被自动释放。

2. 单元测试中的状态污染

在 Jest、Mocha 等测试框架中，测试用例通常期望彼此独立纯净。然而由于单例对象的全局驻留特性，上一个测试用例修改的数据状态会直接遗留给下一个测试用例，极易引发假阳性或假阴性的偶发测试失败。

解决方案是在开发或测试环境下暴露一个专用的重置函数：

// 为单元测试提供的环境重置接口
if (process.env.NODE_ENV === 'test') {
  DatabaseConnector.__resetForTesting = function () {
    instance = null;
  };
}

// 在测试套件中使用：
beforeEach(() => {
  DatabaseConnector.__resetForTesting();
});

3. ES6 模块化（ESM）与 IIFE 闭包单例的关系

在现代打包体系（Webpack, Vite, Rollup）盛行的当下，ES6 模块规范本身就具备原生单例特性：

// store.js
class Store { ... }
export default new Store(); // 模块仅被评估执行一次，导出天然单例

既然 ESM 本身已具备单例缓存，为什么我们依然必须熟练掌握 IIFE 与闭包写法？

• 通用库与 SDK 开发：开发不依赖构建工具的独立 SDK、第三方埋点脚本或微前端主子通信桥梁时，IIFE 是兼容全平台环境、绝不污染宿主全局变量的必备基石。
• 按需与配置动态初始化：ESM 默认在模块加载时即完成实例化（类似于饿汉式）。若希望在业务传参确定的时刻才触发实例化（懒汉式），仍必须借助闭包与获取函数进行管控。

六、总结与关键实践原则

单例模式是软件工程中最直观却也最容易被误用的设计模式之一。通过立即执行函数（IIFE）与闭包的紧密配合，JavaScript 开发者能够在没有传统强类型语言 private static 关键字的早期环境中，构建出兼具高强度数据封装与按需延迟初始化能力的健壮单例。

在日常业务开发中，遵循以下三条准则能让单例模式发挥最大价值：

• 克制使用范围：单例仅应用于全局真正具备唯一物理意义或协调职责的对象（如全局通信总线、模态弹窗系统、硬件接口驱动），不要为了图调用方便将普通业务数据结构包装为单例。
• 首选懒汉式按需加载：将耗时、耗内存的操作延迟至首次真正需要时执行，为应用首屏争取极致的启动速度。
• 预留生命周期回收机制：在闭包内部留好销毁与测试重置途径，确保内存可控、测试隔离，编写出经得起工程化检验的优质代码。