单例和工厂模式非必须，而是为解决特定问题；真正单例需控制构造过程，如用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），否则没必要。
《PHP设计模式指南》中文版
下载
《PHP设计模式》首先介绍了设计模式，讲述了设计模式的使用及重要性，并且详细说明了应用设计模式的场合。接下来，本书通过代码示例介绍了许多设计模式。最后，本书通过全面深入的案例分析说明了如何使用设计模式来计划新的应用程序，如何采用PHP语言编写这些模式，以及如何使用书中介绍的设计模式修正和重构已有的代码块。作者采用专业的、便于使用的格式来介绍相关的概念，自学成才的编程人员与经过更多正规培训的编程人员
立即学习“Java免费学习笔记（深入）”；
- 合理共用场景：日志系统中，
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 个分支、或单例开始承担不该管的状态同步时，就得停下来问问：是不是模型本身该拆了？
