咱们开发者dou有过这种经历吧？深夜盯着屏幕，手里捧着早Yi凉透的咖啡，kan着眼前那一坨仿佛被猫踩过的键盘敲出来的代码，心里默默流泪。尤其是当你接手别人的项目，或者——geng惨一点——面对自己半年前写下的“杰作”时那种想穿越回去抽自己两巴掌的冲动简直无法抑制。满屏的 if-else 像千层饼一样堆叠，改一个变量，整个项目像多米诺骨牌一样崩塌。这时候，所谓的“设计模式”可就真不是面试官用来刁难你的“八股文”了那是前辈们用无数个不眠之夜和秃顶换来的生存智慧啊。

今天咱们不整那些虚头巴脑的理论，直接把那些让人头秃的场景摆上台面：弹窗满天飞、业务逻辑耦合得像解不开的耳机线、表单校验写得像小说……咱们一个个用设计模式这把“手术刀”给它们治好。相信我，kan完这篇，你下次写代码时心里会有底得多。

一、 告别“面条代码”：观察者模式的解耦艺术

先说个Zui经典的场景。你正在Zuo一个电商网站，用户点击“加入购物车”这个按钮。这事儿听起来简单对吧？但实际开发中，这一下点击可不仅仅是把商品存个数据那么简单。产品经理跑过来说：“点击后右上角的小红点数字得变吧？” UI设计师说：“得弹个Toast提示‘添加成功’吧？” 运营同学又补刀：“还得发个埋点数据给我们统计啊。”

于是你的代码可Neng就变成了这样：

function handleAddToCart {
  // 1. 核心业务：把商品塞进购物车数组
  cartData.push;
  // 2. geng新UI角标
  headerBadge.updateCount;
  // 3. 弹出提示框
  toastManager.showMessage;
  // 4. 发送统计数据
  analytics.track;
}

这还好，也就是四行。但明天需求变了要加个“震动反馈”，后天要加个“Ru果库存不足提示库存”。你会发现，handleAddToCart 这个函数越来越臃肿，像个不断被塞垃圾的收纳箱。Zui要命的是这里直接调用了其他模块的方法，headerBadgetoastManageranalytics……这就叫“强耦合”。你想把购物车模块单独抽出来复用？没门，它跟谁dou沾亲带故。

解药：发布-订阅机制

这时候，观察者模式就该登场了。它的核心思想特别简单：别直接喊话，用大喇叭广播。

我们Ke以搞一个全局的“事件中心”，购物车只负责广播：“嘿，我加了个商品！”至于谁听这个广播，那是别人的事。这样一来购物车模块根本不需要知道谁在监听，彻底解耦。

先写个简易的事件总线：

class EventEmitter {
  constructor {
    // 存放所有的事件监听器
    this.eventPool = {};
  }
  // 订阅事件
  subscribe {
    if  {
      this.eventPool = ;
    }
    this.eventPool.push;
  }
  // 发布事件
  publish {
    const callbacks = this.eventPool;
    if  {
      callbacks.forEach);
    }
  }
  // 取消订阅
  unsubscribe {
    // ... 实现移除逻辑
  }
}
// 全局导出一个实例
export const eventBus = new EventEmitter;

现在重构我们的购物车逻辑：

import { eventBus } from './eventBus';
function handleAddToCart {
  // 1. 核心业务保持不变
  cartData.push;
  // 2. 只管发广播，不管谁听
  eventBus.publish('cart_item_added', {
    count: cartData.length,
    product: productItem
  });
}

kankan，清爽多了吧？接下来其他模块各司其职，自己去订阅：

// 头部模块：只关心geng新角标
eventBus.subscribe => {
  headerBadge.updateCount;
});
// 提示模块：只关心弹窗
eventBus.subscribe => {
  toastManager.showMessage;
});
// 埋点模块：只关心数据
eventBus.subscribe => {
  analytics.track;
});

这下明白了吧？以后产品经理再加什么新需求，比如“添加购物车后播放一段音效”，你只需要新建一个音频模块，去 subscribe 一下就完事了完全不用动购物车的一行代码。Vue里的 $emit$on，React里的Redux或者Context，其实骨子里dou是这个思想。

二、 拒绝“俄罗斯方块”：单例模式的唯一性

再来说个让人抓狂的场景。你写了个全局的弹窗组件，用来显示一些重要信息。测试的时候一切正常，结果上线没多久，客服反馈说有用户投诉页面卡死了。你一查日志，好家伙，原来有个手抖的用户，疯狂点击“打开弹窗”的按钮。

因为你的逻辑是“点击一次 -> document.createElement 一次”，结果页面上瞬间堆叠了十几个弹窗DOM节点，像玩俄罗斯方块一样堆满了屏幕。这不仅丑，还极其消耗内存。

function createModal {
  const modalDiv = document.createElement;
  modalDiv.className = 'modal-overlay';
  modalDiv.innerHTML = '
我是弹窗
';
  document.body.appendChild;
}
// 用户狂点，页面爆炸
btn.onclick = createModal;

解药：单例模式

单例模式的核心承诺就是：无论你怎么折腾，全局范围内，我这个类只Neng有一个实例。就像一个国家只Neng有一个总统，不Neng今天你当明天我当。

咱们来改造一下这个弹窗类：

class GlobalModal {
  constructor {
    // 关键点1：Ru果实例Yi经存在直接返回，别重复创建
    if  {
      return GlobalModal._instance;
    }
    // 初始化DOM
    this.element = document.createElement;
    this.element.className = 'modal-overlay';
    this.element.style.display = 'none'; // 默认隐藏
    document.body.appendChild;
    // 关键点2：把实例挂载到类属性上
    GlobalModal._instance = this;
  }
  show {
    this.element.innerHTML = `
${content}
`;
    this.element.style.display = 'block';
  }
  hide {
    this.element.style.display = 'none';
  }
}
// 使用
const modalA = new GlobalModal;
const modalB = new GlobalModal;
console.log; // true，永远是同一个对象

现在不管用户点击多少次new GlobalModal 拿到的永远是第一次创建的那个对象。DOM节点只会被创建一次后续的调用只是修改它的状态。这就叫稳如泰山。

在前端开发中，单例模式其实无处不在。比如 Vuex 或 Pinia 的 Store，整个应用共享一个状态树；再比如全局的 axios 实例，配置一次 baseURL，到处复用。这些dou是单例思想的应用。

三、 粉碎“if-else地狱”：策略模式的灵活之美

Zui后这个场景，我相信99%的程序员dou写过。我们要Zuo一个根据用户等级计算商品折扣的功Neng。

一开始需求hen简单：

function calculatePrice {
  if  {
    return originalPrice;
  } else if  {
    return originalPrice * 0.9;
  } else if  {
    return originalPrice * 0.8;
  }
  return originalPrice;
}

这还好，对吧？但随着业务发展，运营开始搞事情了。突然冒出个“钻石会员”，打75折；双11期间来了个“节日特惠”，不管你是谁dou打8折；企业用户又有单独的折扣逻辑……你的函数开始膨胀：

function calculatePrice {
  if  {
     // ... 节日逻辑
  } else if  {
     // ... 企业逻辑
  } else {
    if  {
       // ...
    } else if  {
       // ...
    } // ... 无限套娃
  }
}

这种代码维护起来简直是噩梦。每次加一个等级，你dou得小心翼翼地钻进这个 if-else 的迷宫里生怕改错了一个符号把其他逻辑搞崩了。这严重违反了编程界的“开闭原则”——对 开放，对修改封闭。你应该Neng加新功Neng，而不需要改动旧代码。

解药：策略模式

策略模式的思路是：把不同的算法单独封装起来让他们Ke以互相替换。就像武侠小说里的高手，内功心法不同，但douNeng打架。

我们Ke以定义一个“策略对象”，把各种折扣逻辑写成一个个函数：

// 定义各种折扣策略
const discountStrategies = {
  // 普通会员不打折
  normal:  => price,
  // 黄金会员9折
  gold:  => price * 0.9,
  // 铂金会员8折
  platinum:  => price * 0.8,
  // 钻石会员75折
  diamond:  => price * 0.75,
  // 节日特惠统一8折
  holiday:  => price * 0.8
};
function getFinalPrice {
  // 直接查表，找到对应的策略函数
  const strategy = discountStrategies;
  // Ru果有策略就执行，没策略就原价返回
  return strategy ? strategy : price;
}

kankan，主函数 getFinalPrice 里是不是一个 if-else dou没有了？逻辑清晰得像泉水一样。

这时候，产品经理又跑来说：“我们要加一个‘黑金会员’，打5折！”

要是以前，你得去翻那几十行的 if-else，找到位置插进去。现在？你只需要在 discountStrategies 对象里加一行：

const discountStrategies = {
  // ... 原有的策略
  blackGold:  => price * 0.5 // 新增策略，搞定
};

主逻辑完全不用动！这就叫优雅。这种模式在表单验证里也特别好用。比如你要验证手机号、邮箱、密码长度，别写一堆 if，把每个验证规则写成策略，然后遍历执行就行。

const validators = {
  required:  => val && val.trim !== '',
  minLength:  => val.length>= len,
  isEmail:  => /^+@+\.+$/.test
};
function runValidation {
  for  {
    // 假设 ruleKey 可Neng是 'minLength:6' 这种带参数的
    const  = ruleKey.split;
    const checker = validators;
    if ) {
      return false; // 只要有一个不通过就挂了
    }
  }
  return true;
}
// 使用
const isValid = runValidation;

把代码写成积木，而不是泥巴

写代码其实跟搭积木差不多。Ru果你把所有东西dou混在一起，那就是一团泥巴，风干了就硬了想改dou改不动。但Ru果你善用设计模式，把业务逻辑拆解成一个个独立的模块，那你的系统就会像乐高城堡一样，稳固又灵活。

今天聊的这三个——观察者、单例、策略，只是设计模式冰山的一角，但它们绝对是解决前端“屎山”代码Zui实用的三板斧。下次当你准备往那个Yi经几百行的函数里再塞一行代码时停下来深呼吸，想一想：是不是该用个模式重构一下了？

相信我，当你把代码重构得清清爽爽，那种成就感，绝对比修好一个Bug要爽得多。你的同事在Review你的代码时也会投来敬佩的目光，而不是在心里默默骂娘。加油吧，让我们的代码不仅“Neng跑”，还要“跑得漂亮”！

---