JavaScript设计模式详解：在大型项目中应用单例与观察者模式

作者：页面旅途时间：2026-10-30 18:32:31浏览：84

深入解析在大型JavaScript项目中单例模式与观察者模式的工程化应用。探讨ES Module模块化单例与懒加载、强类型发布订阅机制、生命周期与内存泄漏治理，以及在微前端和复杂业务架构中的协同落地实践。

在大型 JavaScript 项目的架构演进中，代码混乱的核心源头往往是全局资源访问无序与模块间网状强依赖。单例模式（Singleton）通过严格保证关键资源的全局单一实例与统一切入点来控制状态一致性；观察者模式（Observer / Pub-Sub）则通过解耦事件触发者与响应者，打破跨模块直接调用的复杂依赖网。本文直接从大型系统工程实践出发，拆解这两个模式的落地实现、边界控制与协同机制。

一、单例模式在现代工程中的定位与实现演进

单例模式保证一个类在运行时仅存在一个实例，并向整个运行环境提供该实例的全局访问句柄。在前端应用与 Node.js 基础服务中，配置管理器（ConfigManager）、硬件接口包装（如 WebSocket 适配器、IndexedDB 数据库连接句柄）、以及性能指标采集器（MetricCollector）都需要严格唯一的协调者。若存在多个实例，不仅会造成内存与连接句柄的冗余开销，还会导致状态分叉与读写竞态。

传统的单例实现通常基于类中的静态属性与私有构造器检查。然而在现代 ECMAScript 环境中，模块系统（ES Module）本身就具备天然的单例加载语义。同一模块在同一个执行上下文中被多次 import 时，模块代码仅执行一次，导出的引用对象会被引擎自动缓存。

图1：ES Module 静态单例与基于类静态标记的惰性单例架构原理

大型项目中的可测试单例实现

直接在模块顶部执行重度初始化的 ESM 单例在单元测试中极其脆弱，因为测试用例之间无法隔离状态。以下代码演示了兼顾惰性加载、防止非法直接实例化以及单元测试状态重置能力的单例模式实现：

// AppConfigManager.js
export class AppConfigManager {
  // 私有静态字段保存唯一实例
  static #instance = null;
  // 私有配置仓储
  #configStore = new Map();
  #isInitialized = false;

  // 内部标记，确保只能由内部静态方法调用构造函数
  static #allowDirectConstruction = false;

  constructor() {
    if (!AppConfigManager.#allowDirectConstruction) {
      throw new Error("禁止直接通过 new 调用单例构造器，请使用 AppConfigManager.getInstance()");
    }
  }

  /**
   * 获取全局唯一实例（惰性实例化）
   */
  static getInstance() {
    if (!AppConfigManager.#instance) {
      try {
        AppConfigManager.#allowDirectConstruction = true;
        AppConfigManager.#instance = new AppConfigManager();
      } finally {
        AppConfigManager.#allowDirectConstruction = false;
      }
    }
    return AppConfigManager.#instance;
  }

  /**
   * 写入配置项
   */
  set(key, value) {
    this.#configStore.set(key, Object.freeze(value));
  }

  /**
   * 读取配置项
   */
  get(key) {
    return this.#configStore.get(key);
  }

  /**
   * 专供自动化单元测试使用的实例销毁方法
   * 避免不同测试用例之间的状态污染
   */
  static __resetInstanceForTesting__() {
    if (AppConfigManager.#instance) {
      AppConfigManager.#instance.#configStore.clear();
      AppConfigManager.#instance = null;
    }
  }
}

// 生产业务直接引入默认实例，测试场景可按需引入类本身
export const appConfig = AppConfigManager.getInstance();

避坑提醒： 在服务端渲染（SSR，如 Next.js、Nuxt）架构中，Node.js 进程是长期存活并服务于大量并发请求的。如果在 Node.js 端将用户私有状态（如当前用户信息、Token）存入静态单例，会导致严重的跨请求数据污染。单例模式在大型项目中仅能用于无状态连接池或不可变配置，禁止用作用户级数据容器。

二、观察者模式与发布-订阅模式的解耦机制

大型项目中最常见的架构问题是“紧耦合”。例如：用户在结账页面成功支付后，UI 层需要更新订单状态、埋点系统需要上报流水、库存模块需要扣减预占、即时通讯模块需要通知客服。如果由支付模块直接逐一调用这些下游模块的实例方法，支付模块就会变成一个依赖无数外部实体的庞大“上帝模块”，任何一个下游组件的改动或异常都可能破坏支付主流程。

观察者模式定义了一种一对多的依赖关系，当目标对象发生改变时，所有依赖者都会自动收到通知。而在实际大型前端架构中，通常会采用观察者模式的进化版——发布-订阅模式（Publish-Subscribe Pattern）。它在发布者（Publisher）与订阅者（Subscriber）之间设立了一个专职中介调度中心（EventBus 或 Broker），实现了时间与空间上的完全双向解耦。

图2：经典观察者模式直接耦合与工业级发布-订阅事件总线架构的解耦对比

生产级强健型 EventEmitter 实现

基础教程中常见的事件派发器大多忽略了两个致命隐患：一是当某个监听回调抛出未捕获异常时，整个派发循环直接中断，导致后续订阅者被静默跳过；二是订阅者没有便捷的自销毁机制，开发者极易忘记调用 off()，从而在单页应用（SPA）页面路由切换时留下悬挂引用，导致严重内存泄漏。

生产环境的事件总线应当实现异常沙箱隔离与流式注销闭包：

// EventEmitter.js
export class EventEmitter {
  #events = new Map();

  /**
   * 注册事件订阅
   * 返回一个无需传参即可直接调用的取消订阅函数（Unsubscribe Function）
   */
  on(event, listener) {
    if (typeof listener !== "function") {
      throw new TypeError(`事件监听器必须是函数，当前接收到: ${typeof listener}`);
    }

    if (!this.#events.has(event)) {
      this.#events.set(event, new Set());
    }

    const listeners = this.#events.get(event);
    listeners.add(listener);

    // 返回闭包句柄，便于组件在生命周期钩子中直接卸载
    return () => {
      this.off(event, listener);
    };
  }

  /**
   * 注册一次性事件订阅
   */
  once(event, listener) {
    const unsubscribe = this.on(event, (...args) => {
      unsubscribe();
      listener.apply(this, args);
    });
    return unsubscribe;
  }

  /**
   * 移除指定事件的具体监听器
   */
  off(event, listener) {
    const listeners = this.#events.get(event);
    if (!listeners) return;

    listeners.delete(listener);
    if (listeners.size === 0) {
      this.#events.delete(event);
    }
  }

  /**
   * 触发事件并派发参数
   * 采用防御性浅拷贝遍历与独立的 try-catch 隔离，防止单一监听器崩溃中断整个分发链路
   */
  emit(event, ...args) {
    const listeners = this.#events.get(event);
    if (!listeners || listeners.size === 0) return false;

    // 创建 Set 快照，防止回调函数内部新增或删除监听引发遍历游标错乱
    const snapshot = Array.from(listeners);

    for (const listener of snapshot) {
      try {
        listener(...args);
      } catch (error) {
        // 关键点：隔离异常，记录错误而不向上抛出中断事件循环
        console.error(`[EventEmitter] 事件 '${String(event)}' 监听器执行异常:`, error);
      }
    }
    return true;
  }

  /**
   * 清空所有事件订阅（多用于测试重置或应用退出）
   */
  clear() {
    this.#events.clear();
  }
}

三、单例与观察者模式在架构中的协同落地步骤

在大型前端应用（如多微前端集成的 SaaS 平台、中后台工作台）中，最经典、也是最稳定的协同架构是：以单例模式维护全局统一的状态总线（GlobalStateHub），内部托管观察者机制负责跨系统事件广播。

这套架构既解决了“状态源头不唯一”的问题，又彻底避免了业务模块之间直接调用 API 造成的蛛网状依赖。整个协同流转由五个严密的工程步骤构成：

图3：大型架构中单例状态中心与观察者事件流转的五个关键推导步骤

完整联动代码案例：用户全局会话管理器

以下代码将单例与观察者融为一体，构建了一个健壮的用户全局会话管理模块（SessionManager）。外界业务组件不能随意篡改内部状态，只能通过单例定义好的行为方法来触发状态更新，并自动通过事件驱动各订阅模块响应：

// SessionManager.js
import { EventEmitter } from "./EventEmitter.js";

// 规范事件名称，防止拼写错误
export const SessionEvents = Object.freeze({
  LOGIN_SUCCESS: "session:login_success",
  LOGOUT: "session:logout",
  TOKEN_REFRESH: "session:token_refresh"
});

class SessionManager {
  static #instance = null;
  #bus = new EventEmitter();
  #currentUser = null;
  #token = null;

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

  /**
   * 暴露订阅入口，返回取消订阅回调
   */
  subscribe(event, handler) {
    return this.#bus.on(event, handler);
  }

  /**
   * 业务动作：登录成功
   */
  handleLoginSuccess(userData, token) {
    this.#currentUser = Object.freeze({ ...userData });
    this.#token = token;

    // 触发广播，向外部传递深度冻结的不可变数据快照
    this.#bus.emit(SessionEvents.LOGIN_SUCCESS, {
      user: this.#currentUser,
      timestamp: Date.now()
    });
  }

  /**
   * 业务动作：用户登出
   */
  handleLogout(reason = "user_action") {
    this.#currentUser = null;
    this.#token = null;

    this.#bus.emit(SessionEvents.LOGOUT, { reason, timestamp: Date.now() });
  }

  /**
   * 只读获取当前用户信息，防止外部直接引用污染
   */
  getCurrentUser() {
    return this.#currentUser;
  }
}

export const sessionManager = SessionManager.getInstance();

业务组件使用时的标准化调用示例：

// UserProfileComponent.js
import { sessionManager, SessionEvents } from "./SessionManager.js";

export function mountUserProfile(domElement) {
  // 1. 挂载阶段注册监听，保留解绑函数
  const unbindLogin = sessionManager.subscribe(SessionEvents.LOGIN_SUCCESS, ({ user }) => {
    domElement.textContent = `欢迎您，${user.name} (${user.role})`;
  });

  const unbindLogout = sessionManager.subscribe(SessionEvents.LOGOUT, ({ reason }) => {
    domElement.textContent = `未登录 [${reason}]`;
  });

  // 2. 页面卸载时调用销毁器，杜绝内存泄漏
  return function cleanup() {
    unbindLogin();
    unbindLogout();
  };
}

四、大型项目中的架构边界与陷阱规避

在实际项目重构和代码审查（Code Review）中，单例模式与观察者模式经常因为过度使用或缺乏约束而导致系统难以维护。建立清晰的架构选型矩阵和风险治理规则是工程规范化的必经之路。

图4：单例模式与观察者模式工程落地准则、避坑要点与防御方案全景矩阵

常见问题与调试建议

在大型项目中如何排查悬挂的未注销事件监听器？
可以在调试环境中重写 EventEmitter 的 on() 方法，在注册时利用 new Error().stack 捕获调用栈并保存在元数据中。当页面卸载后，若发现特定事件的监听队列未被清空，即可直接打印对应的创建代码位置。
多包管理（Monorepo）中多个包同时打包会不会导致单例失效？
在 Monorepo 体系下，如果构建工具将同一个单例模块打包进了多个 bundle（或者 npm 安装了多个不同版本），执行环境会存在多个不同的模块作用域，导致单例失效。解决方式是在打包配置中（如 Webpack 的 externals 或 Vite 的 resolve.dedupe）将该单例模块标记为外部共享依赖，或将全局实例挂载于 globalThis 的命名空间属性中作为最终保障。
单例模式和 Redux / Pinia 等全局状态库冲突吗？
两者不冲突，而是处于不同分层。Redux 或 Pinia 管理的是业务领域的“UI 状态数据”；而单例结合观察者管理的是应用底层“基础设施与协议层资源”（如通信适配器、埋点流水线、硬件驱动层）。用单例模式封装基础设施，用领域 Store 托管业务渲染数据，是大型架构分层清晰的标准做法。