JavaScript设计模式是解决常见工程问题的可复用结构方案；单例靠延迟初始化+闭包/静态属性拦截实现唯一实例，工厂用于隔离创建逻辑变化点，模块模式侧重闭包封装私有状态与接口暴露。
new 多个对象却发现状态互相污染？调用过十几个 if/else 分支创建不同类实例却改一处崩一片？这些就是设计模式要直面的问题。
单例模式：为什么不能直接 new Singleton() 就完事？
因为 JavaScript 没有私有构造函数，new Singleton() 默认每次都会新建实例。真正起作用的是「延迟初始化 + 闭包/静态属性拦截」。
- 用闭包实现时，
getInstance()是唯一出口，instance变量被锁在自执行函数作用域里，外部无法篡改或重置 - 用类+静态属性（如
Singleton.instance）更直观，但要注意：如果构造函数没做return this.instance拦截，new仍会生成新对象 - 典型翻车现场：
const s1 = new Singleton(); const s2 = new Singleton(); console.log(s1 === s2); // false—— 就是因为漏了返回拦截逻辑
工厂模式：什么时候该用 createVehicle() 而不是直接 new Car()？
当你发现创建逻辑开始“长胖”：要读配置、要校验参数、要动态加载模块、要兼容老版本 API……这时候就该抽成工厂。
- 简单工厂（函数）适合类型少、逻辑轻：一个
switch返回不同实例即可 - 工厂类（如
ButtonFactory）更适合需要复用状态或组合其他服务的场景，比如预设默认尺寸、绑定事件总线 - 别硬套：如果只有一种类型且永远不变，
new Button()更干净；工厂的价值在于「变化点隔离」，不是为了多写一层函数
模块模式：为什么说它比单例更常用，也更容易被误用？
模块模式本质是「用闭包封装私有变量 + 暴露有限接口」，它不强调“唯一性”，而专注「信息隐藏」——这才是日常开发中更高频的需求。
-
CounterModule里的count是真私有，外部连CounterModule.count都访问不到，比Symbol或#私有字段兼容性更好 - 常见误用：把整个应用塞进一个模块，导致测试困难、热更新失效；正确做法是按功能域拆（如
ApiModule、StorageModule） - 现代替代方案：ESM 的
export/import已天然支持模块化，但模块模式在需运行时动态控制暴露逻辑时仍有不可替代性（比如权限驱动的 API 封装）
