单例模式确保一个类仅有一个实例并提供全局访问点。在javaScript中可通过对象字面量、闭包惰性初始化或es6静态属性实现，如Config类示例所示，多次实例化仍返回同一对象。它常用于管理全局状态，如配置、日志等，优点是节省资源，缺点是隐藏依赖、影响测试和导致状态混乱。现代替代方案包括依赖注入、redux/Pinia等状态管理库及react Context/vue provide/inject，能更好解耦和控制状态。使用单例时应避免可变状态、重置测试数据，并考虑销毁机制。单例本身并非反模式，适用于需唯一实例的场景，但普通状态管理应优先选择更可控方案。
单例模式在javascript中常被用来管理全局状态，但它的使用需要谨慎。核心思想是：一个类只允许创建一个实例，并提供一个全局访问点。虽然这听起来适合管理全局数据，但也容易带来副作用和测试困难。
什么是单例模式？
单例确保某个类在整个应用生命周期中仅有一个实例。在JavaScript中，由于语言的灵活性，实现方式多样，常见的有：
- 对象字面量：最简单的形式，直接定义一个包含方法和属性的对象
- 闭包 + 惰性初始化：延迟创建实例，提高性能
- ES6类 + 静态属性：模拟传统面向对象语言的写法
示例：使用类和静态属性实现单例
class Config { static instance = null; data = {}; constructor() { if (Config.instance) { return Config.instance; } Config.instance = this; } set(key, value) { this.data[key] = value; } get(key) { return this.data[key]; } } const config1 = new Config(); const config2 = new Config(); console.log(config1 === config2); // true
单例与全局状态的关系
单例常常被用作全局状态容器，比如配置管理、日志记录器、状态缓存等。它提供了一个集中读写的接口，但本质上是在维护一块可变的全局数据。
- 优点：避免重复创建资源，减少内存开销
- 缺点：隐藏依赖关系，难以追踪状态变化，不利于单元测试
当多个模块都依赖同一个单例时，任何一处修改都会影响其他部分，容易引发不可预料的行为。
立即学习“Java免费学习笔记（深入）”；
更好的替代方案
现代前端开发中，有更好的方式来管理状态，减少对单例的依赖：
- 依赖注入：显式传递依赖，提升代码可测试性和可维护性
- 模块化状态管理（如Redux、Pinia）：结构清晰，支持时间旅行调试
- React Context 或 Vue provide/inject：框架级解决方案，解耦组件间通信
这些工具虽然也可能维护“全局”状态，但通过明确的更新机制和作用域控制，降低了混乱风险。
使用建议
如果你仍选择使用单例，请注意以下几点：
- 尽量让实例的状态不可变，或通过明确定义的方法修改
- 避免在单例中保存临时或用户交互相关的状态
- 在测试时重置实例状态，防止不同测试用例相互干扰
- 考虑增加销毁或重置方法，便于清理
基本上就这些。单例不是“坏”的模式，关键在于是否用对了场景。对于真正需要唯一实例的服务，它是合理的；但对于普通的状态管理，优先考虑更可控的方式。