789 字
4 分钟
Design mode
Design mode
常用设计模式
观察者 / 发布-订阅模式 (Observer / Pub-Sub)
这是前端生态的灵魂。它的核心思想是解耦：发送者不需要知道接收者是谁，只需要“广播”消息。
- 应用场景： 组件间通信、全局事件总线（Event Bus）。各大框架的响应式更新机制，或者状态管理库中的状态订阅机制，底层都重度依赖这一模式。
单例模式 (Singleton)
确保一个类或对象只有一个实例，并提供一个全局访问点。
- 应用场景： 全局唯一的配置对象或实例。比如封装的全局 Axios 请求实例、单页应用中唯一的路由实例（Router）、全局状态管理的 Store 实例，或者确保全局只出现一次的 Toast 提示框组件。
策略模式 (Strategy)
用来消灭代码里成片、臃肿的 if-else 或 switch-case。将不同的逻辑或算法封装成独立的“策略”对象，可以互相替换。
- 应用场景： 处理表单的多重校验规则、根据不同的 HTTP 状态码执行不同的错误拦截逻辑，或者根据不同用户角色渲染不同的操作面板。通过字典映射（Object Map）来替代条件分支，不仅查找效率高，而且非常容易扩展。
代理模式 (Proxy)
为其他对象提供一种代理以控制对这个对象的访问。
- 应用场景： 浏览器中的事件委托（将子元素的事件代理到父元素上以优化性能）、本地开发时的跨域 API 代理（Dev Server Proxy），以及现代框架用来拦截和劫持数据变更的底层机制。
核心设计原则
单一职责原则 (Single Responsibility Principle, SRP)
一个模块、函数或组件应该只有一个引起它变化的原因。简而言之：一件事只交给一个东西去做。
- 开发实践： 避免写出动辄上千行的“巨型组件”。将纯展示的 UI 代码、复杂的业务逻辑、数据获取和状态管理分离开来。例如，将获取数据的逻辑和副作用抽离成自定义 Hook（如
useFetch），让视图层组件保持纯粹。
开闭原则 (Open-Closed Principle, OCP)
对扩展开放，对修改封闭。当需求增加时，应该通过增加新代码来实现，而不是修改现有的核心代码。
- 开发实践： 在封装通用组件时，尽量利用插槽（Slots）或
children属性来传递动态内容和结构，而不是在组件内部不停地增加新的props和if-else来适应五花八门的新需求。
DRY 原则 (Don’t Repeat Yourself)
不要重复你自己。如果同样的代码或逻辑在系统中出现了两次以上，就应该考虑将其抽象出来。
- 开发实践： 抽离公共的工具函数（Utils）、封装可复用的网络请求和缓存机制、抽取通用的 UI 组件。这不仅能减少代码体积，更能保证后续修改时的一致性。