你的 Node 服務(wù)凌晨 3 點(diǎn)又掛了。監(jiān)控顯示內(nèi)存曲線像爬樓梯，RSS 從 200MB 爬到 2GB，然后進(jìn)程消失。重啟能續(xù)命 6 小時(shí)，但這不是解法——這是麻醉劑。

Node.js 的內(nèi)存結(jié)構(gòu)像一棟四層公寓，每層住著不同的住戶，泄漏點(diǎn)通常藏在最老的那層。

最底層是 OS 內(nèi)存，進(jìn)程本身的房租開銷。往上是 External 內(nèi)存，Buffer 這類原生對象住在這里，V8 管不著。Stack 是調(diào)用棧，函數(shù)進(jìn)進(jìn)出出，用完即走。Heap 才是 V8 的地盤，被切成四個(gè)房間：New Space 給短命對象，Old Space 給老油條，Code Space 存 JIT 編譯后的機(jī)器碼，Large Object Space 專門接待 1MB 以上的大個(gè)子。

泄漏發(fā)生在 Old Space。對象熬過幾次垃圾回收（GC）就會(huì)被晉升到這里，V8 只在重大 GC 時(shí)清理，代價(jià)很高。一旦有人在這里囤積不該留的東西，內(nèi)存就像蓄水池——只進(jìn)不出。

第一滴血：heapUsed 的單調(diào)上升

檢測泄漏不需要復(fù)雜工具。process.memoryUsage() 返回四個(gè)數(shù)字，盯緊 heapUsed 就行。

正常服務(wù)的內(nèi)存曲線應(yīng)該像呼吸：請求來了漲一點(diǎn)，GC 跑了掉一點(diǎn)，長期圍繞某個(gè)基線波動(dòng)。如果 heapUsed 持續(xù)爬升、從不 plateau，這就是泄漏的指紋。

生產(chǎn)環(huán)境建議每 30 秒記錄一次：

每小時(shí)增長 5-10MB 就是泄漏，不需要等到 OOM 才承認(rèn)。

我見過一個(gè)團(tuán)隊(duì)把閾值設(shè)成"內(nèi)存超過 1GB 報(bào)警"，結(jié)果服務(wù)在 900MB 時(shí)已經(jīng)慢得像蝸?！猇8 瘋狂做 major GC，CPU 被占滿，響應(yīng)時(shí)間從 50ms 變成 5 秒。

快照對比：找到那個(gè)不走的租客

最可靠的定位方法：壓測前拍一張堆快照，壓測后拍一張，對比誰留下了。

Node 內(nèi)置了 v8.writeHeapSnapshot()，但別直接暴露到生產(chǎn)環(huán)境。建議加個(gè) IP 白名單，或者只在 staging 開放。

快照文件拖到 Chrome DevTools 的 Memory 面板，看"Retained Size"排序。泄漏對象通常表現(xiàn)為：同一類實(shí)例數(shù)量暴增、或者某個(gè) Map/Set 的 entries 數(shù)跟請求量成正比。

典型翻車現(xiàn)場：

這個(gè) Map 沒有 eviction 策略，用戶越多，內(nèi)存越大，直到爆炸。

修復(fù)很簡單：LRU、TTL、或者直接用 lru-cache 這類庫。但難點(diǎn)在于發(fā)現(xiàn)——很多團(tuán)隊(duì)直到服務(wù)崩潰才意識(shí)到這里有個(gè) Map。

External 內(nèi)存：V8 管不到的盲區(qū)

Buffer、Stream、數(shù)據(jù)庫驅(qū)動(dòng)的底層連接，這些內(nèi)存不在 Heap 里，heapUsed 看不見它們。但 rss 會(huì)漲，external 也會(huì)漲。

一個(gè)常見陷阱：數(shù)據(jù)庫查詢返回大量數(shù)據(jù)，流式處理時(shí)沒及時(shí)銷毀 Buffer。Node 認(rèn)為引用還在，不敢釋放，結(jié)果外部內(nèi)存堆積。

另一個(gè)坑是原生模塊。某次排查中，一個(gè)圖像處理庫的 C++ 部分泄漏了，V8 完全不知情，heapUsed 穩(wěn)如老狗，rss 卻每小時(shí)漲 50MB。

這種泄漏更難抓，需要結(jié)合 rss 趨勢和 Valgrind、或者專門的 native 內(nèi)存工具。

2026 年的新武器：實(shí)時(shí)堆分析

Chrome DevTools 現(xiàn)在支持直接 attach 到運(yùn)行中的 Node 進(jìn)程，不需要停服務(wù)拍快照。對高可用系統(tǒng)來說，這是從"尸檢"到"體檢"的升級(jí)。

原理是 V8 的 Heap Profiler 協(xié)議，Node 啟動(dòng)時(shí)加 --inspect 就行。但生產(chǎn)環(huán)境開 inspector 有安全風(fēng)險(xiǎn)，建議通過 Unix Socket + 權(quán)限控制，或者只在故障節(jié)點(diǎn)臨時(shí)開啟。

更激進(jìn)的方案：持續(xù)采樣堆分配，用算法檢測異常增長模式。Google 的 heap-profiler 和 Uber 開源的 node-flame 都走這個(gè)路線， overhead 控制在 5% 以內(nèi)。

代價(jià)是 CPU，收益是提前 48 小時(shí)預(yù)警泄漏——對電商大促這類場景，值。

某頭部云廠商的內(nèi)部分享：他們用類似方案把內(nèi)存相關(guān)的 P1 故障從年均 12 次降到 1 次，剩下的那次是第三方 SDK 的鍋。

回到那個(gè)凌晨 3 點(diǎn)的崩潰。如果當(dāng)時(shí)有 30 秒粒度的內(nèi)存監(jiān)控，如果能對比兩次快照看到那個(gè)無限增長的 Map，如果 External 內(nèi)存也有獨(dú)立告警——服務(wù)本可以多活 200 天。

你的監(jiān)控里，heapUsed 曲線現(xiàn)在是平的，還是在偷偷爬山？