JavaScript设计模式重在解决具体问题而非套用名称：单例适用于全局唯一且初始化开销大的场景，优先用ES6模块；观察者需支持动态增删、错误隔离与内存清理；策略模式核心是算法可替换与解耦选择逻辑。
JavaScript 里没有“必须用设计模式”的硬性要求，但遇到特定问题时，用对模式能少写一堆修补逻辑的代码。关键不是记名字，而是识别场景、选对工具。
单例模式：什么时候该用 getInstance 而不是直接 new？
当你需要全局唯一实例，且初始化开销大、或依赖状态不可重复创建时才值得上单例。比如日志器、配置管理器、WebSocket 连接句柄。
常见错误是把所有“只用一个”的对象都强行套单例，结果变成隐藏依赖、难以单元测试。
- 用闭包 + 静态属性实现更轻量：
const Logger = (() => { let instance; return { getInstance() { if (!instance) instance = new RealLogger(); return instance; } }; })(); - 避免在构造函数里做异步初始化（如
fetch配置），否则getInstance()可能返回未就绪对象 - ES6 模块本身已是单例——导出一个对象，多次
import拿到的是同一引用，多数场景优先用模块代替手写单例
观察者模式：为什么 addEventListener 是它，而自己写的 on('click') 很可能不是？
原生事件系统是典型观察者：目标对象（button）不关心谁监听，监听者（回调）可随时增删。你自己封装时容易漏掉关键点。
立即学习“Java免费学习笔记（深入）”；
典型翻车现场：监听器执行后没自动解绑、错误没 try/catch 导致后续监听全挂、事件名拼错却无提示。
- 用
Map存事件名 → 回调数组，比对象字面量更易清理：handlers.set('data:update', [cb1, cb2]) - 提供
once()方法时，内部需在首次触发后调用removeListener，别只靠标志位忽略后续调用 - 若用在 React 组件中，务必在
useEffect清理函数里调用off()，否则闭包持有旧 state 引起内存泄漏
策略模式：替代一长串 if/else if 的真正好处不是“看着清爽”
核心价值是让算法可替换、可测试、可独立演进。比如表单校验规则、支付渠道路由、API 错误码映射。
很多人只做到“把分支函数抽成对象”，却没解决上下文传递和策略选择逻辑的耦合问题。
- 策略对象应接收最小必要参数，避免依赖外部变量；例如校验策略接收
{ value, rule }，而不是整个表单对象 - 用
Map或对象字面量做策略注册表，键名尽量用业务语义（'phone','email'），而非技术名（'regex_01'） - 加一层简单工厂函数，根据输入动态选策略：
const getValidator = (type) => validators[type] ?? validators.default;，别让调用方硬编码判断逻辑
设计模式不是贴金标签，是解决具体问题的惯用方案。项目里最常被忽略的是：模式引入后是否真的降低了修改成本？如果加了策略模式，但每次新增一种策略都要改三处注册逻辑、两处类型定义、一个文档，那它就已经在拖慢迭代了。
