Node.js 内存泄漏的预防、排查与监控完全指南
内存泄漏让 Node.js 应用变慢直至崩溃。本文讲清 V8 内存与 GC 原理、泄漏的五大成因、预防实践，以及堆快照分析、Prometheus 指标与生产告警的完整应对方案。
Node.js 内存泄漏的本质是"不再使用的对象仍被引用，GC 无法回收"。高频成因：无限增长的全局缓存/Map、闭包持有大对象、事件监听器只加不删、定时器未清理。排查路径：监控内存趋势 → heapdump 抓快照 → Chrome DevTools 对比分析支配者树，定位泄漏源。
内存与 GC 的基本盘
V8 把堆分为新生代（新对象，Scavenge 快速回收）与老年代（存活久的对象，Mark-Sweep-Compact 深度回收）。GC 只回收"不可达"的对象——只要还有引用链从根（全局、当前执行栈）通到它，对象就活着。泄漏不是"GC 坏了"，而是"你以为断了的引用其实还连着"。
泄漏的五大高频成因
- 无限增长的全局结构：
cache = {}只写不删、Map当万能缓存没有淘汰策略——最经典的泄漏； - 闭包陷阱：长生命周期对象的方法引用局部大对象，整个闭包环境被保留；
- 事件监听器堆积：
emitter.on()在循环/请求里反复注册，从不off()（V8 会警告MaxListenersExceededWarning）； - 定时器未清理：setInterval 引用着大对象，clearInterval 永远不来；
- 被遗忘的队列：任务只进不出，数组/链表持续增长。
预防实践
- 缓存必须有界：LRU（
lru-cache库）+ TTL，别用裸对象当缓存； - 监听器成对管理：注册的时机记下来，销毁时 off；一次性监听用
once； - 定时器在 cleanup 路径统一 clear；长生命周期的 timer 用
unref()； - 流处理大文件，拒绝"全量读进数组"模式；
- 代码评审时多问一句：这个引用谁负责断开？
排查三板斧
// 1. 进程内自检内存趋势
setInterval(() => {
const m = process.memoryUsage();
console.log(`heapUsed: ${(m.heapUsed/1e6).toFixed(0)}MB`);
}, 30000).unref();
// 2. 生成堆快照（heapdump 库或信号触发）
require('heapdump').writeSnapshot('/tmp/' + Date.now() + '.heapsnapshot');
// 3. Chrome DevTools 打开 .heapsnapshot：
// - 拍两张间隔快照，用 Comparison 视图看净增长的对象类型
// - 按 Retained Size 排序，顺支配者树找引用持有者
泄漏对象的"支配者"（持有它的父引用链）在 DevTools 里一览无余——定位到哪个模块的哪个结构，修复就只剩删引用。
观察回收后的堆是否持续增长
内存泄漏判断应比较相近负载下、GC 之后的堆基线，而非只看一次 RSS 峰值。观测云中可结合进程内存、prom-client 暴露的堆与 GC 指标观察趋势，再按 Node.js Profiling 文档采集热点数据。Heap snapshot 可能暂停进程并增加内存占用，应控制采集时机与访问权限；监控趋势用于缩小范围，不能代替对象引用分析。
接入文档：进程监控 · Prometheus 指标采集 · Node.js Profiling。
常见问题（FAQ）
Q：内存涨了就是泄漏吗？
不是。V8 是"懒惰"的：堆会涨到接近上限才深度 GC。判断泄漏看多次 GC 后的水位是否持续抬高（heapdump 对比或 --trace-gc 观察），而非瞬时峰值。
Q：生产环境能直接抓堆快照吗？
可以但要注意成本：写快照时进程停顿（秒级），大堆（数 GB）时更明显。做法：从负载均衡摘流 → 抓快照 → 恢复流量；或在容器副本集群中对单个副本操作。
Q：--max-old-space-size 应该设多大？
默认老年代上限约 2-4GB（64 位）。容器内存 512MB 的应用设 384MB 左右（留堆外空间）。注意这不是"防泄漏"而是"让崩溃来得更早更明确"——配监控告警把崩溃变成可处理的信号。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
