JavaScript单例与工厂模式详解

JavaScript中的单例与工厂模式并非银弹，而是为解决实例复用、创建逻辑解耦等具体问题而生的实用工具；真正的单例需通过静态属性+构造器拦截或模块导出实现，而非简单变量赋值，且须警惕HMR导致的实例重置；简单工厂因简洁灵活成为JS主流选择，工厂方法则仅在需子类定制创建逻辑时才显价值；二者合理共用（如日志系统中工厂函数返回单例实例）能提升可维护性，但盲目套用、过度分层或让单例承担状态同步职责，反而会引入隐晦bug与测试污染——关键不在于“会不会写”，而在于冷静判断：这里是否真的需要这层抽象？

单例和工厂模式在 JavaScript 中确实常用，但它们不是“必须用”的设计模式，而是为了解决特定问题才引入的——比如避免重复初始化、统一管理实例、解耦对象创建逻辑。盲目套用反而会让代码更难维护。

JavaScript 单例模式：怎么写才真正唯一？

很多人以为用 const instance = new MyClass() 就是单例，其实这只是单个变量引用，无法阻止后续再次 new MyClass()。真正的单例要控制构造过程本身。

• 推荐用闭包 + 静态属性组合：在类内部用 static instance 缓存，构造器检查是否已存在，已存在则直接返回
• 注意：ES6 类不支持私有构造器，所以得靠约定或抛错拦截非法调用（如在 constructor 里判断 this.constructor.instance 是否已存在）
• 如果用模块顶层导出一个对象（export default {…}），那它确实是单例，但失去类的可测试性和继承能力，适合配置类、工具类等无状态场景
• 常见错误：在 Webpack 或 Vite 的 HMR 环境下，模块可能被重复执行，导致 instance 被重置——此时需配合 if (!globalThis.__SINGLETON_CACHE) 做全局兜底

简单工厂 vs 工厂方法：该选哪个？

“简单工厂”不是 GoF 23 种之一，但它在 JS 中最常用；“工厂方法”更适合需要子类扩展创建逻辑的场景，JS 中较少见，因为原型链和函数式风格更灵活。

• 简单工厂：一个函数（如 createLogger(type)），根据参数返回不同实例，适合类型少、逻辑稳定的情况
• 工厂方法：让每个子类实现自己的 createProduct()，JS 中常被策略对象替代（如 { file: () => new FileLogger(), console: () => new ConsoleLogger() }）
• 别硬套 UML 类图——JS 里工厂函数可以返回类实例、对象字面量、甚至 Promise，只要封装了“如何创建”的细节就算达成目标
• 性能上没差异，但过度抽象工厂（比如为两个构造器写三层工厂）会增加调用栈和阅读成本

单例和工厂一起用：典型误用与合理场景

有人把工厂做成单例（const factory = new LoggerFactory()），再让工厂返回单例实例——这属于叠床架屋。除非工厂自身有状态（比如缓存了连接池、加载了远程 schema），否则没必要。

• 合理共用场景：日志系统中，LoggerFactory 是简单工厂函数，而 ConsoleLogger 是单例（因 console 是全局的，多次 new 无意义）
• 误用信号：工厂方法里出现 if (type === 'A') return new A(); else if (type === 'B') … 且分支持续增长 → 应改用注册表模式（register(type, ctor)）或动态 import()
• 测试时注意：单例会污染测试上下文，单元测试前需手动重置 MyClass.instance = null 或用 jest.mock 模拟模块

真正难的不是写出符合教科书定义的单例或工厂，而是判断“这里是否值得加一层抽象”。JS 的灵活性意味着很多模式只是临时补丁——当发现要给工厂加第 5 个分支、或单例开始承担不该管的状态同步时，就得停下来问问：是不是模型本身该拆了？

今天关于《JavaScript单例与工厂模式详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！