JavaScript单例与工厂模式详解

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《JavaScript常见设计模式：单例与工厂应用详解》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

单例和工厂模式非必须，而是为解决特定问题；真正单例需控制构造过程，如用static instance加构造器检查；简单工厂更常用，工厂方法适合需子类扩展的场景；二者合理共用如日志系统，误用则增加复杂度。

单例和工厂模式在 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学习网公众号！