17370845950

JavaScript中无标准设计模式列表，只有经高频验证解决真实痛点的几类套路：单例模式确保全局唯一实例避免状态不同步；工厂模式解耦对象创建逻辑；观察者模式实现松耦合状态通知。

JavaScript 中没有所谓“标准设计模式列表”，只有**被高频验证过、解决真实痛点的几类套路**。它们不是语法规范，而是老手在反复踩坑后，对“怎么组织代码更稳、更易改、更少出错”的经验提炼。

单例模式：为什么不能直接 new 多次？

当你需要一个全局唯一对象（比如配置管理器、日志实例、弹窗控制器），直接 new Config() 两次，就等于创建两个互不通信的配置副本——状态不同步、内存浪费、行为不可控。

• 典型错误：用 class Singleton { constructor() { if (Singleton.instance) return Singleton.instance; ... } }，但没封死 new 调用路径，仍可能绕过判断
• 更安全写法是彻底避开 new：用闭包封装实例，只暴露 getInstance()
• 注意：ES6 模块本身已是单例（import 同一文件多次，模块脚本只执行一次），很多场景下直接用模块就够了，不必硬套单例类

const Logger = (function () {
  let instance;
  function create() {
    return {
      log: (msg) => console.log(`[LOG] ${msg}`)
    };
  }
  return {
    getInstance() {
      if (!instance) instance = create();
      return instance;
    }
  };
})();

工厂模式：什么时候该把 new 拆出去？

当你的代码里出现大量条件判断来决定创建哪个类（比如 if (type === 'pdf') return new PdfExporter(); else if (type === 'csv')...），这就是工厂模式的明确信号——它把“怎么造”和“造完怎么用”剥离开。

• 简单工厂（非严格 GOF）最常用：一个函数接收参数，返回具体实例，比如 createValidator(rule)
• 别在工厂里做业务逻辑（如校验、请求），只负责实例化；否则工厂会越来越重，违背“单一职责”
• 如果类型太多、规则变频繁，建议配合策略模式：工厂只管“选谁”，策略负责“怎么干”

class ApiClient {
  constructor(baseURL) { this.baseURL = baseURL; }
}
class MockClient {
  constructor() { this.isMock = true; }
}

const ClientFactory = {
  create(type, options = {}) {
    switch (type) {
      case 'real': return new ApiClient(options.url);
      case 'mock': return new MockClient();
      default: throw new Error(`Unknown client type: ${type}`);
    }
  }
};

观察者模式：比 addEventListener 更通用的状态通知机制

addEventListener 是观察者模式的一种实现，但它绑定在 DOM 上；而真正的观察者模式适用于任何 JS 对象之间的松耦合通信，比如状态变更通知、跨模块响应、表单联动等。

• 核心陷阱：忘记取消订阅（unsubscribe），导致内存泄漏或重复触发
• 现代替代方案：RxJS 的 Subject、Vue 的 watch、Redux 的 store.subscribe 都是它的变体，但底层思想一致
• 不用自己从零写事件总线——除非你明确知道要控制粒度（比如按命名空间隔离、支持异步通知）

class EventBus {
  constructor() {
    this.events = {};
  }
  on(event, callback) {
    if (!this.events[event]) this.events[event] = [];
    this.events[event].push(callback);
  }
  emit(event, data) {
    (this.events[event] || []).forEach(cb => cb(data));
  }
  off(event, callback) {
    if (this.events[event]) {
      this.events[event] = this.events[event].filter(cb => cb !== callback);
    }
  }
}

真正难的不是记住模式名字，而是识别出“这里正在重复写同一类结构”——比如三次以上手动维护一个缓存对象、五处地方都在拼接相同条件生成不同实例、或者改一个功能要同时动七八个文件里的事件绑定……这些才是设计模式该出手的地方。