设计模式的价值在于识别并解决经典耦合问题，而非机械套用；Factory适用于运行时配置依赖等场景；Observer适合内部状态流，EventEmitter适合I/O事件；Singleton在前端多为反模式，应优先用模块级单例或依赖注入。
JavaScript 不需要“为了学设计模式而学设计模式”。真正值得投入时间的，是当你在维护一个多人协作、生命周期超过半年、模块间耦合开始变重的项目时，发现 if 嵌套越来越深、new 出来的对象职责不清、状态散落在十几个回调里——这时候设计模式不是银弹，但能帮你把混乱显式化。
哪些场景下 Factory 比直接 new 更可靠
当构造逻辑依赖运行时配置、需要统一拦截实例化过程、或不同环境返回不同子类实例时，硬写 new SomeClass() 会快速失控。
- 比如前端 SDK 需要根据浏览器支持情况返回
IndexedDBStorage或LocalStorageFallback，用工厂函数封装判断逻辑，调用方完全不感知底层差异 - 测试时可轻松替换工厂返回 mock 实例，避免真实副作用
- 注意别把工厂写成巨型
switch：一旦分支超过 4 个，考虑结合Map或策略模式预注册构造器
Observer 和 EventEmitter 的边界在哪
原生 addEventListener 已经是观察者模式实现，但它的事件名是字符串、无类型约束、无法跨 iframe 或跨模块统一管理。自建轻量 Observer 类更适合内部状态流。
- Vue 2 的响应式系统底层就是
Observer+Dep，它让数据变化和视图更新解耦，但代价是劫持Object.defineProperty - Node.js 的
EventEmitter更适合 I/O 或生命周期事件（如'connect'、'error'），它自带最大监听器数警告、异步执行保障，但不适合高频状态变更（如鼠标移动） - 现代项目中，优先用
Proxy+ 自定义钩子替代传统Observer，避免对数组索引赋值等边界失效问题
为什么 Singleton 在前端多数是反模式
单例强调“全局唯一实例”，但在前端，页面刷新即重置、多标签页互不通信、SSR 服务端与客户端环境隔离——所谓“唯一”根本不可靠。
立即学习“Java免费学习笔记（深入）”；
- 常见误用：用单例缓存 API 响应，结果用户在另一个 tab 登录不同账号，看到旧数据
- 真正需要的是“当前上下文唯一”，比如某个 React 组件内部的
useRef缓存实例，或 Zustand store 的单例导出（本质是模块级单例，非全局） - 如果真要跨模块共享状态，用依赖注入（如通过顶层
Provider注入）比自己getInstance()更可控、更易测
设计模式的价值不在名词本身，而在你能否一眼识别出“这里正在重复解决某个经典耦合问题”。与其背口诀，不如下次遇到 props 穿透三层组件时，停下来想：是不是该把这部分逻辑抽成独立的可观察对象？
