Node.js EventEmitter 的原理、同步执行和内存泄漏风险是什么？

简化版

EventEmitter 是 Node.js 中事件发布订阅的基础模型，emit 时会按注册顺序同步调用监听器。它适合解耦事件生产者和消费者，但要注意错误事件、监听器清理和监听器过多导致的内存泄漏警告。

详细版

常用 API：

on(event, listener)：注册监听。
once(event, listener)：只监听一次。
off/removeListener：移除监听。
emit(event, ...args)：触发事件。

重要细节：

监听器默认同步执行，不是自动异步。
'error' 事件如果没有监听器，可能导致进程抛错退出。
长生命周期对象上反复注册监听却不移除，会造成引用无法释放。
监听器过多时会出现 MaxListenersExceededWarning，它是泄漏信号，不应简单调大上限掩盖。

完整版教学

一、EventEmitter 是 Node 事件模型的基础积木

Node.js 里很多对象都带事件能力，例如流、服务器、请求、进程对象等。它们背后都体现了 EventEmitter 的思想：对象在某个时刻发出事件，关心这个事件的人提前注册监听器。

import { EventEmitter } from 'node:events';

const bus = new EventEmitter();

bus.on('login', (user) => {
  console.log('welcome', user.name);
});

bus.emit('login', { name: 'Ada' });

这种模型适合处理“一个事件可能有多个后续动作”的场景。登录后写日志、发通知、刷新缓存可以拆成多个监听器，而不是全部硬编码在登录函数里。

但它不是消息队列。EventEmitter 发生在同一进程内，默认不持久化、不跨进程、不保证失败重试。

二、emit 默认同步调用监听器

很多同学以为“事件”就一定异步，但 Node 官方事件模型里，emit 会按监听器注册顺序同步调用它们。只有监听器内部自己使用 setImmediate、process.nextTick、Promise 或其他异步 API，才会切到异步。

const bus = new EventEmitter();

bus.on('task', () => console.log('A'));
bus.on('task', () => console.log('B'));

console.log('start');
bus.emit('task');
console.log('end');

输出是：

start
A
B
end

这点很关键。如果某个监听器执行 200ms 的 CPU 计算，emit 调用方也会被卡 200ms。EventEmitter 解耦的是代码依赖，不自动提供并发能力。

三、on、once、off 的生命周期管理

on 会持续监听，once 会在第一次触发后自动移除。对于只需要一次结果的事件，例如连接建立、初始化完成、单次确认，once 通常更安全。

bus.once('ready', () => {
  console.log('init only once');
});

function onMessage(msg) {
  console.log(msg);
}

bus.on('message', onMessage);
bus.off('message', onMessage);

移除监听器时必须传入同一个函数引用。下面这种匿名函数就很难移除：

bus.on('message', (msg) => console.log(msg));
// 后面无法 off 掉同一个匿名函数引用

在 WebSocket、定时任务、长连接、插件系统里，生命周期管理尤其重要。连接关闭时不清理监听器，就可能让用户对象、请求上下文、缓存数据继续被引用。

四、error 事件是特殊边界

'error' 事件在 Node 中有特殊地位。很多 EventEmitter 如果触发 'error' 时没有对应监听器，会把错误抛出，严重时导致进程退出。

const bus = new EventEmitter();

bus.on('error', (err) => {
  console.error('handled', err.message);
});

bus.emit('error', new Error('boom'));

为什么这样设计？因为错误不能悄悄吞掉。一个流读取失败、连接异常、解析错误，如果没有任何地方处理，继续运行可能造成数据错乱。Node 倾向于让未处理错误显性暴露。

工程里要给关键 emitter 绑定错误处理，特别是 stream、socket、子进程和自定义任务总线。错误处理里要记录上下文、释放资源，并决定是否重试、降级或终止流程。

五、监听器泄漏是引用泄漏

EventEmitter 内部会保存事件名到监听器列表的映射。监听器函数又可能闭包引用外部对象。如果监听器没有移除，这些对象就可能无法被垃圾回收。

function handleConnection(socket) {
  const userCache = new Array(10000).fill(socket.user);

  globalBus.on('refresh', () => {
    console.log(userCache.length);
  });
}

假设每个连接都注册一个 refresh 监听器，1 分钟 1000 个连接，10 分钟就是 10000 个监听器。每个监听器还引用 userCache，内存会持续增长。

globalBus
  -> listener[]
     -> closure
        -> userCache
        -> socket/user

这类泄漏常发生在“全局事件总线 + 请求级数据”的组合里。请求结束、连接关闭、组件卸载时，要移除对应监听器。

六、MaxListenersExceededWarning 不要粗暴忽略

Node 默认会在同一事件监听器数量超过阈值时发出警告。这个阈值不是硬限制，而是提醒你可能存在泄漏。

做法	是否推荐	原因
检查是否重复注册	推荐	找到根因
使用 `once` 替代长期监听	推荐	自动释放
在关闭时 `off`	推荐	生命周期闭环
直接 `setMaxListeners(0)`	谨慎	可能掩盖泄漏

确实存在一个事件需要很多监听器的场景，例如插件系统或大型订阅中心，可以合理调大上限。但调大前要确认监听器数量增长是可预期的，而不是每次请求都多一个。

记忆钩子：监听器不是“轻飘飘的回调名”，它是一个强引用入口。谁注册，谁负责在生命周期结束时清理。

七、常见误区与追问

误区：EventEmitter 的监听器默认异步执行。 emit 默认同步按顺序调用监听器，异步要监听器自己切换。
误区：MaxListenersExceededWarning 只是烦人的警告。 它通常提示监听器数量异常增长，应该先排查生命周期。
误区：匿名监听器也能随时移除。 移除需要同一个函数引用，匿名函数后续很难精确 off。
追问：error 事件为什么特殊？ 未监听的错误可能直接抛出，避免关键失败被静默吞掉。
追问：once 适合什么场景？ 只需要一次结果的初始化、连接成功、单次响应，能减少忘记清理的风险。
追问：EventEmitter 和消息队列有什么区别？ EventEmitter 是进程内同步事件模型，消息队列通常跨进程、可持久化、可重试。

八、加强记忆

EventEmitter 可以记成“同步发布订阅”：on 注册，emit 同步按顺序触发，once 自动清理，off 手动清理，error 必须重视。它解决模块解耦，不解决并发和可靠投递。只要抓住“监听器是强引用”，内存泄漏风险就能解释清楚。

简化版

详细版