Node.js 中的 EventEmitter 是异步事件的核心机制，但如果监听器绑定后没有妥善清理，很容易造成内存泄漏。这种泄漏在开发阶段不容易察觉，往往到线上出现 GC 频繁或内存持续增长时才暴露。下面从判断依据、操作取舍和检查方法三个角度说明定位思路。
判断依据：内存为什么只涨不降
当EventEmitter绑定的事件监听器没有被正常移除时，监听器函数会持续持有对外部作用域中变量的引用，导致这些变量无法被垃圾回收。可以使用process.memoryUsage()监控堆内存变化，或在Chrome DevTools Memory面板中抓取堆快照，查找Detached EventEmitter或大量闭包。如果多次触发事件后堆内存持续增长且不回落，通常意味着存在未清理的监听器。
这是最直接的判断方式。在实际排查中，可以先在本地用一个小脚本模拟频繁触发事件，观察内存曲线。如果内存每次触发后都上升一个台阶且不下降，基本可以确认监听器未释放。注意，有些 Node.js 版本下的 GC 行为有差异，需要确认环境。通常建议先使用 global.gc() 配合 --expose-gc 标志手动触发 GC，排除自动 GC 的干扰。
操作取舍：绑定监听器后何时清理
在绑定事件的模块中，明确所有监听器的移除时机。对于一次性事件，使用emitter.once()替代emitter.on()。对于持续监听的事件，务必在合适的生命周期钩子（如组件的销毁回调、请求完成回调）中调用emitter.removeListener()或emitter.removeAllListeners()。如果无法控制移除时机，可以考虑使用WeakRef或Symbol来弱化引用，但需注意兼容性。
这里的关键是“明确时机”。在 Express 或 Koa 应用中，每个请求都可能绑定事件到全局 EventEmitter，如果不在请求结束时移除，这些监听器会一直留在内存里。对于一次性事件，once 会自动移除自身，但注意如果事件从未被触发，它仍然会占位。另外，removeListener 需要传入与绑定相同的回调函数引用，因此通常需要将回调保存为变量。如果用的是箭头函数匿名回调，则无法通过引用移除，只能使用 removeAllListeners，但这会清除该事件的所有监听器，可能影响其他模块。
如果项目使用了 React 或 Vue 等前端框架，在组件卸载（类似 componentWillUnmount）中移除监听器是常见做法。但如果是纯后端服务，需要自己在路由或请求的 finally 块中处理。
检查方法：利用内置警告和堆快照
利用Node.js内置的process.on('warning')和--trace-warnings标志，可以捕获EventEmitter的警告信息。当监听器数量超过默认限制（默认为10）时，会打印'MaxListenersExceededWarning'。在代码中主动调用emitter.getMaxListeners()和emitter.listenerCount(event)可以统计当前监听器数量，辅助排查泄漏。另外，使用heapdump模块生成堆快照，结合Chrome DevTools的Comparison视图对比快照，能直观看到新增的监听器对象。
启动 Node 进程时加上 --trace-warnings 可以打印警告的堆栈信息，方便定位是哪段代码绑定了过多监听器。在生产环境，可以将 process.on('warning') 与日志系统结合，记录警告详情。但需要注意，MaxListenersExceededWarning 默认只在监听器数量超过 10 时触发，如果设置过大的 maxListeners，可能掩盖泄漏。建议在开发阶段设置较小的 emitter.setMaxListeners(5) 来提前暴露问题。
堆快照是比较彻底的方式。使用 heapdump 模块在内存增长前后各生成一份快照，然后在 Chrome DevTools 中加载并选择 Comparison 模式，过滤 "Detached" 或 "EventEmitter" 相关对象，就能看到哪些监听器没有被释放。操作时需要确保对比的是同一 EventEmitter 实例。
常见陷阱与风险边界
一个常见的误解是认为EventEmitter在emit结束后会自动清理监听器。实际上，除非显式移除或emitter本身被垃圾回收，否则监听器会一直存在。另一个陷阱是在回调函数内部创建闭包却忘记在回调执行后清理。例如，在HTTP请求处理中为每个请求绑定事件监听，若请求结束后不移除，这些监听器会随着请求数增加而累积。此外，使用第三方库（如EventEmitter3或mitt）时需确认其行为是否相同，部分库可能不提供移除方法。
内存泄漏初期可能仅表现为GC压力增大和偶发延迟，但积累到一定量后会导致进程内存溢出（OOM）。监听器数量超过默认限制时会触发警告，但不会直接阻止绑定，因此需要主动设置合理的最大监听器数。对于长时间运行的服务，建议定期使用heapdump或clinic.js等工具进行内存分析，设定内存增长告警阈值。注意，EventEmitter的泄漏可能与其他原因（如全局变量、定时器）叠加，排查时需综合判断。
如果已经确认是 EventEmitter 泄漏，但无法通过上述方法定位具体模块，可以尝试在绑定监听器时添加额外的上下文标记。例如，创建一个包装类，在监听器上挂载自定义属性记录绑定的来源文件和行号，这样在堆快照中就能直接看到。
以上是定位 EventEmitter 内存泄漏的通用流程。最终效果依赖具体代码结构，建议先在小范围模拟验证，再应用到全量环境。