JavaScript观察者模式应用与实现

本文深入浅出地剖析了JavaScript中观察者模式的核心实现——一个不到20行代码却功能完备的EventEmitter，它通过为每个事件名维护回调数组，真正支持多监听、精准移除和业务可扩展性；文章明确指出DOM原生addEventListener无法替代它，因其受限于DOM上下文、缺乏逻辑解耦能力与定制空间，并直击开发中on/off引用不一致、异步emit反模式、滥用场景等高频陷阱，最终强调：精简可靠的同步实现才是工程实践的基石，而何时“不用”事件机制，往往比如何实现更考验架构判断力。

什么是 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 的事件名和参数）、防抖控制、异步队列等业务定制逻辑。

• 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，否则监听函数会被淹没。

本篇关于《JavaScript观察者模式应用与实现》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！