Node.js 在处理高频异步 I/O 方面表现出色，但其基于 V8 的垃圾回收机制在面对复杂的闭包和事件监听时，容易暴露出内存泄漏的风险。由于 V8 默认的堆内存上限（在 64 位系统下通常约为 1.4 GB，尽管较新版本可自动适配），一旦持续泄漏，应用很快就会遭遇 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 进而崩溃。
排查 Node.js 内存泄漏的核心在于获取运行时的堆快照（Heap Snapshot）。堆快照完整记录了内存中所有对象的分布状况及引用关系。在生产环境中直接抓取快照可能会导致进程短暂阻塞，因此通常需要在流量低谷期或隔离出的单台节点上进行。
借助原生的 v8 模块，我们可以在代码中动态生成快照：
“`javascript
const v8 = require(‘v8’);
const fs = require(‘fs’);
function takeSnapshot(filename) {
const snapshotStream = v8.getHeapSnapshot();
const fileStream = fs.createWriteStream(filename);
snapshotStream.pipe(fileStream);
}
“`
将获取到的 .heapsnapshot 文件导入 Chrome DevTools 的 Memory 面板，是定位问题的关键环节。推荐的做法是采集两个不同时间点的快照，利用 DevTools 的 Comparison（对比）视图。通过比较前后的对象分配差异，那些被分配但始终没有被垃圾回收器清理的对象（通常表现为 Delta 值为正且数量持续增长的对象组）就会浮出水面。
最常见的泄漏源往往是未被注销的事件监听器（Event Emitters）和不合理的闭包引用。例如，在每个 HTTP 请求到达时向全局对象或长时间存活的 Socket 连接添加监听器，若在请求结束时未调用 removeListener，这些回调函数及其引用的上下文将永远驻留在内存中。通过 DevTools 中的 Retainers（保留者）视图，可以清晰地看到是一条怎样的引用链阻止了对象的回收，进而反推到具体的业务代码行。
在橙星云的后端架构演进中，我们也曾遭遇过类似的微服务内存持续攀升问题。橙星云技术团队引入了基于内存阈值的自动快照机制：当某个容器的内存使用率持续 10 分钟超过 85% 时，系统会自动触发一条指令抓取快照并上传至诊断存储桶，随后重启进程。这种设计保证了服务在不熔断的前提下，为开发人员保留了第一手的现场数据。
确认泄漏点后，修复工作通常涉及清理全局数组、确保事件侦听器成对出现与销毁、或者重构涉及大对象的闭包逻辑。修复完成后，通过压测工具持续发起请求，观察内存曲线是否从持续上升转变为健康的锯齿状（即垃圾回收正常介入并释放空间），方可认为内存问题得到了彻底解决。