如何实现Javascript的观察者模式_怎样用Javascript构建发布订阅系统？

EventEmitter 的最小可用实现是用不到20行代码支持on、emit、off三个方法，并为每个事件名维护回调数组以支持多次绑定；不能用addEventListener替代，因其仅限dom元素且缺乏业务定制能力。

什么是 EventEmitter 的最小可用实现？

javaScript 本身没有原生的 EventEmitter 类，但用不到 20 行就能写出一个可落地的发布订阅核心。关键不是封装多漂亮，而是能处理 on、emit、off 三个动作，且支持同一事件绑定多个回调。

常见错误是把事件回调存在普通对象里（如 { click: fn }），导致无法支持多次 on('click', fn1) 和 on('click', fn2)；正确做法是为每个事件名维护一个数组。

• on(event, callback)：将 callback 推入 this._events[event] || [] 数组
• emit(event, ...args)：遍历该事件对应数组，逐个调用 callback(...args)
• off(event, callback)：用 Array.prototype.indexOf 找到并 splice 删除指定函数（注意引用必须相同）

class EventEmitter {   constructor() {     this._events = Object.create(null);   }   on(event, callback) {     if (!this._events[event]) this._events[event] = [];     this._events[event].push(callback);   }   emit(event, ...args) {     const cbs = this._events[event];     if (cbs) cbs.forEach(cb => cb(...args));   }   off(event, callback) {     const cbs = this._events[event];     if (cbs) {       const i = cbs.indexOf(callback);       if (i > -1) cbs.splice(i, 1);     }   } }

为什么不能直接用 addEventListener 替代自定义 EventEmitter？

addEventListener 只作用于 DOM 元素，而观察者模式常用于纯逻辑解耦：比如状态管理、模块通信、跨组件通知。你没法对一个 class Store 调用 store.addEventListener('change', ...) —— 它根本不是 EventTarget 实例。

另一个现实限制是兼容性：CustomEvent 在 IE 中不支持，而手写 EventEmitter 可以跑在任何 ES5+ 环境；同时，自定义实现能轻松加入调试钩子（如打印每次 emit 的事件名和参数）、防抖控制、异步队列等业务定制逻辑。

立即学习“Java免费学习笔记（深入）”；

• DOM 事件只响应用户交互或浏览器生命周期，不适用于数据流驱动场景
• EventTarget 不提供 off 的批量取消能力（removeEventListener 必须传入原函数引用）
• 无法监听“尚未创建的事件名”，而手写实现可提前 on('user:login')，再在任意位置 emit('user:login', user)

如何避免 off 失效这个高频坑？

最常踩的坑是：用箭头函数或内联函数绑定事件，然后试图用另一个箭头函数去移除 —— 因为函数引用不同，off 完全不起作用。

例如：emitter.on('data', (x) => console.log(x))，后续写 emitter.off('data', (x) => console.log(x)) 是删不掉的。必须复用同一个函数引用。

• 把回调声明为具名函数或变量：const handler = (x) => {...}; emitter.on('data', handler); emitter.off('data', handler);
• 如果必须用匿名函数，可在 on 时返回一个取消函数：const unwatch = emitter.on('data', fn); unwatch();（需改写 on 返回闭包）
• 支持通配符或正则匹配事件名的高级用法，会进一步增加 off 的复杂度，不建议初版引入

要不要给 emit 加上异步调度？

默认同步执行回调是最简单也最符合直觉的设计。加 Promise.resolve().then(() => ...) 或 setTimeout 做异步调度，看似“更安全”，实则引入了非预期时序问题：订阅者无法确定自己是在当前任务还是下一个微任务中被调用，容易引发竞态或状态不一致。

真正需要异步的场景（如日志上报、分析埋点）应由使用者自行包裹，而不是在 emit 层统一强制异步。框架级库（如 node.js 的 events 模块）也坚持同步调用，这是经过大量实践验证的边界选择。

• 同步调用便于调试：堆栈清晰，错误能准确定位到哪个回调抛出
• 若某回调可能长时间阻塞，应由它自己移交到 Web Worker 或 setTimeout(..., 0)
• 强行异步会破坏“发布即消费”的因果直觉，尤其在单元测试中难以断言执行顺序

实际项目里，90% 的观察者需求靠上面那个 EventEmitter 类就足够了。难点不在实现，而在什么时候不该用它——比如两个组件有明确父子关系，直接 props / context 传递比发事件更可控；又比如高频事件（每秒几十次的鼠标移动），应节流后才 emit，否则监听函数会被淹没。