JavaScript中真正高价值的设计模式包括Module、Factory/Builder、Singleton（慎用）、Pub/Sub和Decorator；是否采用取决于具体问题，而非盲目套用。
JavaScript 没有“标准设计模式清单”，但有若干被长期验证、在真实项目中高频出现的模式，它们不是语法特性，而是解决特定架构问题的惯用法。是否采用，取决于你正在面对的问题——比如状态分散、对象创建复杂、事件耦合过重、或逻辑难以复用。
哪些模式在现代 JS 项目里真正有用
不是所有经典 GoF 模式都适合 JS。动态原型、闭包、函数一等公民等特性让某些模式变得多余（如 Strategy 常直接用函数参数替代），而另一些则因框架演进而退场（如 Observer 在 React/Vue 中大多被响应式系统接管）。
当前仍高频、高价值的包括：
-
Module（ESM 或 IIFE 封装）：隔离作用域，控制暴露接口，避免全局污染 -
Factory/Builder：当对象构造逻辑变复杂（如配置合并、依赖注入、条件实例化）时，比裸new更可控 -
Singleton（谨慎使用）：仅适用于真正需要单实例的场景，如日志器、缓存容器、WebSocket 连接管理器；注意测试时难 mock -
Pub/Sub（轻量事件总线）：解耦非父子组件通信，比CustomEvent更灵活，但别替代状态管理库 -
Decorator（配合function或class）：用于横切关注点，如日志、权限校验、重试逻辑；TypeScript 支持装饰器语法，但 Babel/TS 编译需开启experimentalDecorators
怎么判断该不该加一个模式
加模式不是为了“看起来专业”，而是为降低后续修改成本。一个信号是：你开始反复写相似结构的代码，且每次都要手动处理生命周期、依赖顺序、错误兜底或状态同步。
例如：
- 多个 API 调用都带 loading/error/data 三态管理 → 考虑封装成
useApi自定义 Hook（React）或createResource（SolidJS），本质是Factory + State组合 - 表单字段验证规则散落在各处、难以复用 → 提取为独立
validate函数，配合Rule对象配置，属于Strategy的轻量实现 - 类方法频繁需要检查
this.isDestroyed→ 不要硬塞一堆if，改用Proxy包裹或在基类中统一拦截（即Proxy模式变体）
容易踩的坑：过度设计 vs. 模式滥用
最常见问题是把简单问题套进复杂模式，结果代码更难读、更难调试、更难测试。
典型表现：
- 为 2 个函数写一个
Command类，再配Invoker和Receiver，但实际从未需要撤销或排队 - 用
Mediator管理两个组件通信，而它们本可通过 props 或 context 直接传递 - 所有类都继承自
BaseService，但里面只有空的init()和destroy()，没实际逻辑 - 在 Node.js CLI 工具里强行套
Abstract Factory，而实际只有一种实现
记住：模式是处方，不是补药。JS 的灵活性恰恰在于——多数时候，一个纯函数、一个闭包、或一个导出对象，就是最合适的“模式”。
提升架构质量的关键不在模式数量，而在约束意识
真正影响可维护性的，往往不是用了什么模式，而是有没有明确边界和约定：
- 模块职责是否单一？
utils/里是否混着工具函数、常量、类型定义、甚至副作用代码？ - 状态变更是否可追踪？
setState是否只发生在明确位置（如 reducer、service 方法），而非散落在事件回调深处？ - 异步是否被统一处理？
fetch是否都经过同一层封装（自动加 token、错误分类、超时控制）？ - 类型是否收敛？
interface User是定义在 domain 层，还是每个 API 文件里各自声明一个不兼容版本？
这些比记住 5 种模式更重要。很多所谓“架构问题”，根源是缺乏最小约束，而不是模式不够多。
