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 的事件名和参数）、防抖控制、异步队列等业务定制逻辑。
- 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) - 强行异步会破坏“发布即消费”的因果直觉，尤其在单元测试中难以断言执行顺序
EventEmitter 类就足够了。难点不在实现，而在什么时候不该用它——比如两个组件有明确父子关系，直接 props / context 传递比发事件更可控；又比如高频事件（每秒几十次的鼠标移动），应节流后才 emit，否则监听函数会被淹没。
