Cursor实战案例-运维监控-98-内存泄漏深度排查：使用memlab诊断长连接WebSocket中的堆栈内存溢出

memlab 实战：WebSocket 交易长连接内存泄漏及闭包泄露诊断排查

[!NOTE]
在量化实盘交易和前端行情大屏中，系统需要维持 7*24 小时的高并发 WebSocket 长连接以订阅 Tick 级行情与成交推送。然而，如果客户端重连机制编写不当、或者在事件监听器中错误地引用了全局上下文闭包，会导致垃圾回收（GC）无法释放无用对象。随着运行时间推移，进程虚拟内存会不断膨胀，最终引发 Out Of Memory (OOM) 崩溃。本案例基于 Meta 开源的自动化内存分析框架memlab，详细剖析了 WebSocket 重连逻辑中的闭包泄露机密。系统通过编写自动化 Puppeteer 交互场景测试脚本，模拟频繁建立、断开和重连 WebSocket，自动触发垃圾回收并比对堆快照（Heap Snapshot），精准输出堆栈保留路径（Retainer Trace），秒级定位泄漏元凶。

一、问题背景与技术选型

研发团队在维护常驻内存的行情订阅服务或 SPA 可视化大屏时，普遍面临以下排障痛点：

1. 泄漏极其隐蔽：内存泄露往往不是瞬间爆发的，而是像“慢性毒药”一样，每小时上涨 5MB。普通的单元测试根本无法感知这种盘中长跑累积的崩溃风险。
2. 人工快照对比效率极低：使用 Chrome 开发者工具的 Memory 面板手动抓取多个 Heap Snapshot，然后在数以万计的 JS 树节点中人眼对比Shal