单例和工厂模式非必须，而是为解决特定问题；真正单例需控制构造过程，如用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），否则没必要。
立即学习“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 个分支、或单例开始承担不该管的状态同步时，就得停下来问问：是不是模型本身该拆了？
