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