Systematically diagnose and ro…

# 定位内存泄漏接口的排查方案

一、先确认现象特征

• 时间点分析：502从昨天15:00开始，先查PM2日志确认重启频率，以及流量/定时任务在15:00是否有新增（如新版本发布、新功能上线、定时任务启动）
• 区分“泄漏”与“突增”：查看PM2 pm2 monit 或历史监控，判断内存是缓慢爬升不回落（典型泄漏），还是某个时间点后突增（流量暴增或大查询）

二、定位接口：三种手段

1. HTTP 日志聚合（最快）

• 分析Nginx/网关access log，统计15:00后QPS变化最大、响应时间变长的接口
• 重点排查：返回大数据的接口（如未分页的列表）、上传/导出、涉及大JSON处理的接口

2. 堆快照对比（核心手段）

```bash

# 进程内存高时连续拍两次快照，间隔几分钟

# 使用 Chrome DevTools 或 heapdump / v8.writeHeapSnapshot()

```

• 用 DevTools 的 Comparison 视图对比两次快照，按 Delta 降序排列
• 重点关注：String、Object、Array、闭包持有对象数量持续增长的地方，顺着Retainers链找到业务代码

3. PM2 + 代码静态排查

• pm2 logs 确认是否OOM被kill（pm2 describe <app> 看重启原因）
• 检查常见泄漏模式：
• 全局缓存无上限（Map/Object 只增不减）
• 事件监听器未解绑（EventEmitter 超限警告）
• 定时器未清理（setInterval 持有闭包）
• 未关闭的数据库连接/流

三、紧急止损

• PM2 设置内存阈值自动重启（如 max_memory_restart: '1G'），先保证服务可用
• 若能定位到可疑接口，临时降级或限流该接口

四、验证与修复

• 本地压测复现：对该接口压测，观察RSS是否持续不回落
• 修复方向：缓存加上限/TTL、大结果集分页、避免同步阻塞大对象操作
• 修复后观察24-48小时内存曲线确认恢复平稳

建议顺序：先看日志锁定可疑接口 → 拍堆快照实锤 → 修复验证。两万日活规模下，快照对比通常一小时内可定位。