单例模式用于全局唯一状态与延迟初始化，如日志器、配置管理器；观察者模式解决松耦合通知，需支持错误隔离与生命周期管理；二者组合时应职责分离，避免“上帝对象”。
单例模式和观察者模式是 JavaScript 中最常用、也最容易被误用的两种设计模式；它们不是“必须用”，而是“在特定约束下最有解”。
什么时候该用单例模式？getInstance 不是装饰，是防重复实例的兜底
单例的核心诉求只有一个：全局唯一状态 + 延迟初始化。常见于日志器、配置管理器、全局事件总线（注意：这里和观察者不冲突，只是职责不同）。
容易踩的坑：
- 用
const instance = new MyClass()直接导出 —— 模块缓存虽能保证“唯一”，但无法控制初始化时机，也无法做懒加载或条件初始化 - 把单例写成带私有变量的闭包，却暴露了构造函数，导致别人仍可
new MyClass()绕过控制 - 在 SSR 环境中未区分服务端/客户端实例，造成状态污染
一个稳妥的实现（ES6+）：
立即学习“Java免费学习笔记（深入）”；
class Logger {
constructor() {
if (Logger.instance) return Logger.instance;
this.logs = [];
Logger.instance = this;
}
log(msg) { this.logs.push(msg); }
}
// 导出的是方法，不是实例
export const getLogger = () => Logger.instance || new Logger();
关键点：构造函数内拦截、导出函数而非实例、不暴露 new 能力。
观察者模式 ≠ addEventListener，它解决的是“松耦合通知”
浏览器原生事件机制是观察者的一种特例，但通用观察者要支持任意对象间通信，且不依赖 DOM。典型场景：状态变更通知多个无关模块（如 UI 更新、埋点上报、缓存失效）。
常见错误：
- 用
Array.push存回调，但没做去重或生命周期管理，导致内存泄漏（尤其 React 组件反复挂载） - 通知时直接遍历执行，若某个观察者抛错，后续观察者中断 —— 缺少错误隔离
- 把发布者和订阅者写死在同一个类里，失去解耦意义
轻量实现（无第三方依赖）：
class EventEmitter {
constructor() {
this.events = new Map();
}
on(type, handler) {
if (!this.events.has(type)) this.events.set(type, new Set());
this.events.get(type).add(handler);
}
off(type, handler) {
if (this.events.has(type)) {
this.events.get(type).delete(handler);
}
}
emit(type, ...args) {
const handlers = this.events.get(type);
if (handlers) {
// 错误隔离：每个 handler 独立 try/catch
handlers.forEach(h => { try { h(...args); } catch (e) { console.error(e); } });
}
}
}
使用时：emitter.on('user:login', updateHeader)，谁注册谁注销，不强绑定生命周期。
单例 + 观察者组合用？小心“上帝对象”陷阱
比如写一个全局 Store 单例，并内置 on/emit —— 听起来合理，但很快会演变成所有逻辑都往里塞：API 请求、权限校验、本地缓存同步……最后变成难以测试、无法拆分的巨石。
更健康的分法：
- 单例只管“状态容器”本身（如
class Store { state; setState() }） - 观察者独立存在（
const bus = new EventEmitter()），由上层协调：Store 变更后手动bus.emit('store:changed', newState) - 或者用 Proxy + 自动触发（需谨慎：性能开销、不可控通知粒度）
复杂点从来不在“怎么写模式”，而在于“哪一层该承担哪部分责任”。模式是工具，不是架构说明书。
