Node.js消费RabbitMQ变慢主因是内存泄漏导致heapUsed持续上涨，引发Mark-Sweep-Compact GC频繁执行、STW延长，进而拖慢channel.consume回调、降低吞吐、升高nextTick延迟。
为什么 heapUsed 持续上涨会拖慢消费速度？
Node.js 的 V8 引擎在老生代（Old Space）堆内存持续增长时，会频繁触发 Mark-Sweep-Compact GC。这类 GC 耗时可达几十毫秒甚至上百毫秒，且会暂停 JS 执行（Stop-the-world）。一旦 heapUsed 从 100MB 涨到 800MB，GC 频次和单次耗时都会显著上升，直接表现为：channel.consume 回调执行变慢、消息处理吞吐下降、process.nextTick 延迟升高。
- 用
process.memoryUsage()定期打点，重点关注heapUsed和heapTotal的比值 —— 若长期 > 0.7，说明内存碎片多、GC 效率低 - 加
--trace-gc --trace-gc-verbose启动，观察日志中是否出现Mark-sweep频次陡增、单次耗时 >50ms - 不要只看 RSS：RSS 高可能是缓存或共享库，真正影响 GC 的是
heapUsed
检查未移除的 EventEmitter 监听器
RabbitMQ 官方客户端（amqplib）大量使用 EventEmitter，比如 connection.on('error')、channel.on('close')、consumerTag 对应的内部事件监听。若在重连逻辑中反复 channel.consume 却没清理旧的 consumer，就会堆积监听器，每个监听器都持有一个闭包上下文，引用着大对象（如 buffer、JSON 解析结果）。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 用 Chrome DevTools 的 Memory 面板拍两个堆快照，筛选
Listener或Function类型，看数量是否随消费时间线性增长 - 检查代码中所有
.on()调用，确认是否有对应.removeListener()或.off()；特别注意重连场景下是否复用了旧channel实例 - 避免在
consume回调内动态注册监听器（例如每次收到消息都emitter.on('done', ...)）
排查闭包意外持有 large data 的场景
典型模式是：消息体解析后生成大对象（如 JSON.parse(msg.content.toString())），然后传给某个闭包函数处理，但该闭包被挂到全局变量、定时器或未清理的事件上，导致整个数据结构无法回收。
- 搜索代码中类似
const payload = JSON.parse(...)+setTimeout(() => { use(payload) }, 1000)的组合 —— 若 timeout 未 clearTimeout，payload 就一直活着 - 检查数据库操作封装层：是否把原始
msg或解析后的payload作为参数传给了 ORM 的 save 方法，并被 ORM 内部缓存（如 TypeORM 的 identity map） - 用
heapdump生成快照后，在 Chrome DevTools 的Retainers视图里展开一个疑似泄漏的大数组，往上追溯谁在引用它 —— 常见根节点是Closure→Timeout→global
留意 amqplib 内部 channel 和 connection 的复用陷阱
amqplib 的 channel 不是线程安全的，也不适合长期复用。如果在高并发消费中手动维护 channel 缓存池，又没控制最大 channel 数或没做健康检查，会导致 channel 内部状态（如未确认 delivery 缓存、未关闭的 reply-to queue）持续膨胀，间接增加 JS 堆压力。
- 不要自己实现 channel 池；优先用
channelWrapper（如bach库）或每条消息用独立短生命周期 channel（配合channel.close()） - 确认
channel.consume的noAck: false场景下，是否遗漏了channel.ack()或channel.nack()—— 积压的 unacked 消息会让 channel 内部缓存 delivery 元数据 - 检查
connection.on('close')回调里是否调用了channel.close()；否则 channel 进程残留，其关联的 buffer 和 closure 无法释放
