深坑預警！90% 前端工程師都踩過的內存泄漏陷阱，一鍵優化性能翻倍

作者：JavaScrip 2025-02-21 13:00:00

在 JavaScript 中，垃圾回收器會自動回收不再使用的內存，但如果我們的代碼中存在一些阻止垃圾回收器正常工作的因素，就會導致內存泄漏。

在構建高性能、流暢的 Web 應用時，內存管理至關重要。如果處理不當，內存泄漏會導致應用運行緩慢、卡頓，甚至崩潰，嚴重影響用戶體驗。作為前端開發者，我們經常與 JavaScript 打交道，而 JavaScript 的垃圾回收機制雖然強大，但并非萬無一失。稍有不慎，就可能埋下內存泄漏的隱患。

什么是內存泄漏？

簡單來說，內存泄漏是指程序中已經不再需要的內存，但由于某種原因沒有被釋放，導致這部分內存無法被再次利用，從而造成內存資源的浪費。在 JavaScript 中，垃圾回收器會自動回收不再使用的內存，但如果我們的代碼中存在一些阻止垃圾回收器正常工作的因素，就會導致內存泄漏。分享下幾個比較常見的前端內存泄漏場景及其解決方案：

1. 被遺忘的定時器和回調函數

當我們使用 setInterval 或 setTimeout 設置定時器，或者設置了事件監聽器、訂閱發布等回調函數后，如果沒有及時清除，即使這些定時器或回調函數已經不再需要，它們仍然會駐留在內存中，導致相關變量無法被回收。

坑點示例：

解決方案：

在組件卸載或不需要定時器時，使用 clearInterval 或 clearTimeout 清除定時器。
移除事件監聽器使用 removeEventListener。
取消訂閱發布模式中的訂閱。

優化示例：

2. 脫離 DOM 樹的 DOM 元素引用

當我們使用 JavaScript 變量引用了某個 DOM 元素，即使這個 DOM 元素已經從 DOM 樹中移除，由于 JavaScript 變量仍然持有對它的引用，該 DOM 元素及其子元素都無法被垃圾回收。

坑點示例：

解決方案：在 DOM 元素不再需要時，將引用該 DOM 元素的 JavaScript 變量設置為 null。

優化示例：

3. 閉包使用不當

閉包是 JavaScript 的強大特性，但如果不注意，也可能導致內存泄漏。如果閉包中引用了外部作用域的變量，即使外部函數已經執行完畢，這些變量也不會被垃圾回收，因為閉包仍然保持著對它們的引用。

坑點示例：

解決方案：

謹慎使用閉包，避免不必要的變量引用。
如果確實需要使用閉包，在閉包不再需要時，手動解除對外部變量的引用，例如將閉包變量設置為 null。

優化示例：

4. 全局變量的濫用

全局變量只有在頁面關閉時才會被回收。如果定義了過多的全局變量，或者將一些臨時變量錯誤地掛載到全局對象上，會導致這些變量一直占用內存，直到頁面關閉。

坑點示例：

解決方案：

盡量避免使用全局變量，使用 let 或 const 聲明局部變量。
使用立即執行函數 (IIFE) 或模塊化方式來管理代碼，減少全局變量的暴露。

5. 未關閉的 WebSocket 連接

WebSocket 提供了持久的雙向通信通道。如果創建了 WebSocket 連接，但在不再需要時沒有正確關閉，該連接會一直占用資源，導致內存泄漏。

坑點示例：

解決方案：

在不需要 WebSocket 連接時，使用 socket.close() 方法關閉連接。
可以在組件卸載或頁面關閉時，統一關閉 WebSocket 連接。

優化示例：

6. Map 和 Set 的不當使用

Map 和 Set 是 ES6 引入的新數據結構。如果使用不當，也可能導致內存泄漏。例如，如果將對象作為 Map 的鍵或 Set 的成員，并且沒有手動刪除這些鍵值對或成員，即使這些對象已經不再需要，它們仍然會被 Map 或 Set 引用，無法被垃圾回收。特別是當鍵名是復雜對象時，內存占用會非常明顯。

坑點示例：