JavaScript常用设计模式有哪些？单例为何常用于模块化

JavaScript设计模式是开发者基于语言特性（如闭包、函数一等公民、原型链等）提炼出的可复用解决方案，不拘泥于语法规范，却深刻影响着代码的可维护性、协作效率与扩展能力；其中单例模式尤为关键——它通过确保全局唯一实例并提供统一访问点，有效遏制全局变量污染、避免资源重复创建（如日志器、配置中心）、支撑跨模块状态共享，更因天然契合ES6模块机制（多次import指向同一对象）及IIFE封装范式，成为模块化开发中实现“分而治之”又“合而为一”的核心黏合剂，兼具数量控制与私有封装双重优势。

JavaScript设计模式，是开发者在长期实践中总结出的、针对常见问题的可复用解决方案。它不是语法规定，也不是强制标准，而是基于JS语言特性（比如函数是一等公民、闭包、原型链、无类私有修饰符等）形成的编码“套路”。这些模式帮助组织代码结构、管理状态、解耦逻辑、避免全局污染，让项目更易维护、协作和扩展。

单例模式解决什么实际问题

单例模式的核心就两点：确保一个类/模块在整个应用中只存在唯一实例，并提供统一入口访问它。它直击JS早期开发中的几个痛点：

• 全局变量泛滥：直接挂载到window上的变量容易重名、覆盖、难以追踪。单例把相关功能收敛到一个对象里，相当于建了个“专属抽屉”，不干扰其他代码。
• 资源重复创建：比如日志器、配置管理器、状态中心、HTTP客户端——这些通常只需一份实例。反复 new 或初始化不仅浪费内存，还可能导致状态不一致。
• 跨模块共享状态或工具：多个组件需要读取同一份配置、共用同一个事件总线，单例天然适配这种“一份数据、多处使用”的场景。

为什么它在模块化中特别常见

模块化本质是“分而治之”，但分完还得能“合得自然”。单例恰好是模块间低耦合协作的黏合剂：

• 模块系统默认就是单例：像 RequireJS、ES6 Module（import 同一路径多次）都保证模块代码只执行一次，导出对象即为单例。你 import './utils' 十次，拿到的永远是同一个对象引用。
• 闭包 + 对象 = 模块化单例雏形：早期没有原生模块时，开发者用 IIFE（立即执行函数）包裹逻辑，返回一个对象——内部变量被闭包保护（私有），返回属性方法对外暴露（公有）。这既是模块模式，也是单例实现。
• 避免重复初始化副作用：比如一个模块里含 DOM 初始化、监听绑定、定时器启动，若允许多实例，页面可能绑一堆重复事件、启多个定时器。单例天然规避这类风险。

单例和模块模式的关系

模块模式常被看作单例的一种增强实践。它不止强调“唯一”，更强调“封装”：

• 单例关注数量控制（只有一个）；
• 模块模式在此基础上，用闭包模拟私有域，只暴露明确 API，隐藏实现细节和内部状态。
• 所以你在项目里看到的 const api = (function(){ let token; return { login(){...}, getToken(){return token;} }; })();，它既是单例（只执行一次），也是模块（token 不可外部修改）。

今天关于《JavaScript常用设计模式有哪些？单例为何常用于模块化》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！