设计模式本身不提升代码质量，滥用反而降低可维护性；真正起作用的是对问题场景的准确识别与恰当模式的克制使用。工厂函数适用于构造逻辑分散或需隐藏实现的轻量场景，应避免条件分支堆积；观察者模式应优先使用 EventTarget 或 EventEmitter；单例模式在前端几乎总是错误，需警惕模块耦合与 SSR 问题；模式的价值在于解决实际问题，而非追求形式规范。
设计模式本身不提升代码质量，滥用反而降低可维护性；真正起作用的是对问题场景的准确识别 + 恰当模式的克制使用。
什么时候该用工厂函数而不是 class
当你需要创建的对象行为高度相似、但构造逻辑分散（比如不同来源的配置解析器），或需隐藏内部实现细节时，factoryFunction 比 class 更轻量、更易测试。
- 避免在工厂里写大量条件分支——那说明你其实该用策略模式
-
new关键字不是必须的：工厂返回 plain Object 也能满足大部分场景 - 若工厂返回的实例需共享方法，优先用
Object.create(prototype)而非反复挂载方法到每个对象
观察者模式别直接手写 notify / subscribe
手写 notify 容易漏掉异常捕获、订阅者移除、执行顺序控制等问题。现代项目应优先考虑：
- 用
EventTarget（浏览器环境）或node.js的EventEmitter，它们已处理异步队列、错误传播和内存泄漏防护 - 若需响应式更新（如状态变更触发 ui 渲染），
proxy+WeakMap组合比手动维护观察者列表更可靠 - 警惕“订阅即永久”：未清理的
addEventListener或未解绑的subscribe是常见内存泄漏源
单例模式在前端几乎总是错的
浏览器中没有真正的全局生命周期，“只初始化一次”的需求往往掩盖了模块耦合或状态污染问题。
立即学习“Java免费学习笔记（深入）”；
-
export const instance = new Service()看似是单例，实则依赖模块加载顺序，SSR 下可能出错 - 真正需要“唯一实例”的场景（如 websocket 连接管理），应配合连接状态检查 + 错误重试，而非仅靠构造控制
- 多数所谓“工具类单例”（如日志、缓存）更适合用依赖注入方式传入，便于单元测试 mock
模式的价值不在名字，而在它帮你把“重复踩坑”变成“重复验证”。最常被忽略的不是怎么写，而是：这个模式是否真在解决当前问题，还是只是让代码看起来更“规范”。