【亲测好用】前端设计模式的最佳解决方案

【亲测好用】前端设计模式的最佳解决方案

前端设计模式不是花里胡哨的八股，而是针对页面、组件、状态、请求、渲染、业务解耦这些高频痛点的成熟套路。没有万能模式，核心原则：优先简单，按需选用;避免过度设计。下面按前端最常用场景，整理亲测落地的方案、适用场景、代码思路、避坑点。

前置共识：现代前端(Vue / React / 原生 JS)优先组合式、hooks、composition-api，传统类(class)模式作为补充;不要为了套模式强行写复杂抽象。

一、创建型模式：对象怎么造

1. 工厂模式(Factory)✅ 高频推荐

解决：根据类型动态产出不同组件 / 实例，消除大量 if-else /switch。适用：表单控件、弹窗、图表、不同类型卡片。思路：把实例创建逻辑收拢到工厂函数，外部只传 type、config。

function createComponent(type, props) {

const map = { input: Input, select: Select, date: DatePicker }

return map[type] ? h(map[type], props) : null

}

避坑：不要工厂无限膨胀;类型太多抽成配置表，再用注册机制(注册器模式)。

2. 单例模式(Singleton)✅ 非常常用

解决：全局唯一实例，只初始化一次。适用：全局弹窗、全局请求实例、全局事件总线、全局 toast、websocket。

class Toast {

static instance

static getInstance() {

if (!Toast.instance) Toast.instance = new Toast()

return Toast.instance

}

}

避坑：慎用!滥用单例容易全局状态污染、测试困难;优先依赖注入替代全局单例。

3. 建造者模式(Builder)

解决：复杂对象分步构造，参数巨多、配置项繁杂。适用：复杂图表配置、长表单、复杂弹窗(标题 / 按钮 / 回调 / 样式)。特点：链式调用 .setTitle().setOkText().onConfirm()。避坑：简单对象不要上建造者，徒增代码。

二、结构型模式：对象怎么组合、包装

1. 装饰器模式(Decorator)✅ 强烈推荐

解决：在不修改原函数 / 组件源码的前提下，增加能力。适用：请求加 loading、权限校验、埋点、防抖节流包装、日志。 React HOC、Vue 高阶组件、函数包装本质就是装饰器。

const withLog = (fn) => (...args) => {

console.log('调用参数', args)

return fn(...args)

}

避坑：多层装饰嵌套时顺序很关键;不要用来处理复杂业务逻辑。

2. 适配器模式(Adapter)✅ 业务神器

解决：接口格式不一致，新旧接口、第三方 SDK 返回字段不统一。适用：后端改接口字段、对接多端接口、兼容老版本数据、适配第三方组件入参。核心：一层转换层，对外输出统一结构，业务层不动。

这是项目里性价比最高的模式之一，很多人不知不觉在用。

3. 代理模式(Proxy)

解决：访问对象前增加拦截、校验、缓存、权限。适用：缓存请求、权限拦截、图片懒加载、Vue2 响应式底层就是 Proxy(Object.defineProperty)。区分：代理控制访问;装饰器增强行为。

4. 组合模式(Composite)

解决：树形结构，叶子节点和容器节点调用方式一致。适用：菜单、树组件、嵌套表单、目录树。

三、行为型模式：对象之间怎么通信、协作

1. 观察者 / 发布订阅(PubSub)✅ 前端标配

解决：解耦组件通信，跨层级、跨页面通知。适用：跨组件消息、全局事件、websocket 消息分发。

区分：观察者模式是对象绑定;发布订阅多一层事件中心，前端一般直接用发布订阅。避坑：忘记解绑 → 内存泄漏;事件名散落在各处，建议常量统一管理。

2. 策略模式(Strategy)⭐ 替代巨量 if else 首选

解决：同一行为有多种算法，可动态切换。适用：不同校验规则、不同格式化、不同导出方式、不同支付渠道。

const strategy = {

number: v => !isNaN(v),

email: v => /@/.test(v)

}

function validate(type, val) {

return strategy[type](val)

}

优点：新增规则只加配置，不用改主函数，符合开闭原则。

3. 状态模式(State)

解决：对象行为由内部状态决定，状态切换自动改变逻辑。适用：异步请求状态(loading/success/error)、订单状态机、表单多步骤。和策略区别：策略是同一场景不同算法;状态是状态流转驱动行为变化。复杂状态机强烈推荐状态模式，避免一堆 if(status === 'xxx')。

4. 命令模式(Command)

解决：动作封装成对象，支持撤销、重做、队列执行。适用：画布编辑器、富文本、拖拽画板、批量操作。

5. 迭代器模式(Iterator)

解决：统一遍历不同数据结构。JS Symbol.iterator 原生支持，表格、自定义树遍历常用。

四、现代前端专属方案(比传统 GOF 模式更贴合业务)

传统 23 种设计模式是面向面向对象时代，现在前端有一批更适配的实践方案，日常优先级甚至高于经典模式：

容器 / 展示分离(Container/Presentational)：React 经典，容器管状态请求，展示组件只接收 props 渲染。

组合优于继承：Vue 组合式 API、React hooks，替代类继承。

模块模式：IIFE 闭包，隔离私有变量，原生 JS 项目常用。

Render Props：复用组件逻辑，现在大多被 hooks 替代。

状态管理模式：单向数据流(Flux/Redux)，适合全局复杂状态，不要滥用。

五、场景直接查表(亲测最优选择，拿来就选)

大量 if-else 判断、多种校验 / 格式化 → 策略模式

接口字段混乱、新旧接口兼容 → 适配器模式

跨组件通信、消息通知 → 发布订阅

全局唯一实例(toast、axios) → 单例(谨慎)

给函数加埋点、loading、权限包装，不改原代码 → 装饰器

树形菜单、嵌套节点 → 组合模式

订单、多步骤表单、请求状态流转 → 状态模式

根据 type 渲染不同组件 → 工厂模式

编辑器支持撤销重做 → 命令模式

六、最容易踩的大坑(重点)

模式优先，业务次之：新手通病，上来硬套模式，简单逻辑写一堆抽象，可读性变差。能写简单 if 就不要上策略;能 props 透传就不用发布订阅。

单例泛滥：全局变量、全局单例越多，单元测试越难，并发场景容易串数据。

发布订阅滥用：到处触发事件，链路黑盒，出问题很难追溯。

分不清装饰器 / 代理 / 适配器：

适配器：转格式，适配输入输出

装饰器：在原有基础上加功能

代理：控制访问，拦截

忽略 hooks 天然的组合能力：很多 OOP 设计模式在 hooks 里会简化，不需要硬写 class。

七、落地建议(最佳实践)

优先使用组合、hooks、配置驱动;经典设计模式作为工具，而不是规范。

先写可运行版本，业务稳定、发现逻辑膨胀之后，再重构引入模式，不要前置过度抽象。

封装原则：高内聚、低耦合、开闭原则(对扩展开放，对修改关闭)。

小项目：适配器、策略、发布订阅足够覆盖 90% 场景;大复杂中台，再引入状态模式、工厂、命令模式。

一句话总结：前端设计模式的最佳方案，不是背诵 23 种模式，而是按业务痛点匹配模式，能用简单方案就不抽象;适配器、策略、装饰器、发布订阅是业务开发里性价比最高的四大主力。