JavaScript常见设计模式有哪些？

JavaScript设计模式是针对常见开发痛点的成熟解决方案，不追求炫技而是切实提升代码的可维护性、复用性和团队协作效率；文章重点解析了最实用的四大模式——模块模式（巧妙封装私有状态）、观察者模式（天然契合前端事件驱动场景）、工厂模式（统一复杂对象创建逻辑）和单例模式（安全管控全局唯一资源），并延伸介绍了代理、策略、装饰器等高频补充模式，同时强调关键原则：模式是为解决问题而存在，而非堆砌概念，真正有价值的实践是让变化更集中、扩展更安全、理解更直观——从模块化、解耦通信、对象创建这三大日常高频场景入手，就已覆盖绝大多数JS开发需求。

JavaScript 中的设计模式不是“必须用”，而是解决特定问题时的成熟思路。它不改变语言能力，但能提升代码可维护性、复用性和协作效率。由于 JS 动态、函数一等、原型链灵活，很多经典模式（如工厂、观察者、单例）实现更轻量，也催生了像模块模式、混合模式这类 JS 特色实践。

最常用且实用的 4 种模式

1. 模块模式（Module Pattern）——组织代码、封装私有变量
JS 原生不支持块级私有作用域（ES6 之前），模块模式通过立即执行函数（IIFE）+ 闭包实现“公开接口 + 私有成员”。

• 典型写法：const Counter = (function() { let count = 0; return { increment() { count++; }, getCount() { return count; } }; })();
• 现代替代：ES6 import/export 是标准模块系统，但模块模式仍用于需私有状态的工具类、插件初始化等场景。

2. 观察者模式（Observer Pattern）——解耦事件通知逻辑
前端大量依赖事件响应（用户操作、数据变化、生命周期钩子），观察者天然契合。

• 原生体现：addEventListener 就是观察者；CustomEvent 可自定义广播。
• 手动实现要点：维护订阅者列表、提供 subscribe/unsubscribe/notify 方法；Vue 的响应式系统、RxJS 的 Observable 都是其增强变体。

3. 工厂模式（Factory Pattern）——统一创建对象，隐藏实例细节
当对象构造逻辑复杂（如需根据参数选不同类、加载异步资源、做兼容处理），避免到处 new。

• 简单工厂示例：function createButton(type) { if (type === 'primary') return new PrimaryButton(); return new DefaultButton(); }
• 适合场景：组件库中按配置生成 UI 组件、API 客户端根据环境返回不同适配器（mock / fetch / axios）。

4. 单例模式（Singleton Pattern）——全局唯一实例，控制资源访问
不是“全局变量”，而是确保类只被实例化一次，常用于状态管理、日志器、配置中心。

• JS 实现简洁：class Logger { static instance = null; static getInstance() { if (!Logger.instance) Logger.instance = new Logger(); return Logger.instance; } }
• 注意：过度使用单例会增加隐式依赖，测试困难；优先考虑依赖注入或顶层 Provider（如 React Context）。

其他高频出现的模式

代理模式（Proxy Pattern）——拦截对象操作
ES6 Proxy 原生支持，Vue 3 响应式核心、权限控制、缓存代理、日志埋点都基于它。

• 例子：const handler = { get(target, prop) { console.log(`读取 ${prop}`); return target[prop]; } }; const p = new Proxy({a: 1}, handler);

策略模式（Strategy Pattern）——封装算法，运行时切换
把不同校验规则、排序逻辑、渲染方式抽成独立函数/类，通过配置选择执行哪个。

• 常见于表单验证：{ email: validateEmail, phone: validatePhone }，调用时 validators[type](value)。

装饰器模式（Decorator Pattern）——动态增强对象功能
ES2022 装饰器提案（@语法）虽未完全落地，但高阶函数（HOC）、中间件（Express/Koa）、React 的 withRouter 等都是其实质体现。

什么时候该用？什么时候别硬套？

• 用：当重复出现相似结构（如多个类都要发请求+加 loading+错误重试），说明存在可抽象的模式。
• 别用：为用而用（比如给一个只有两个方法的对象强行套“桥接模式”）；小项目、一次性脚本、POC 阶段，先跑通再重构。
• 关键判断：这个模式是否让“变化点更集中、扩展更安全、理解成本更低”？如果不是，就暂缓。

不复杂但容易忽略：设计模式的价值不在“用了多少种”，而在是否让团队更容易读懂、修改和扩展同一段逻辑。从模块化、事件解耦、对象创建这三处下手，已覆盖绝大多数 JS 日常开发痛点。

本篇关于《JavaScript常见设计模式有哪些？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！