那個幾乎沒人提卻超好用的 React Hook 清理范式
上周我在排查一個讓 React 應用性能直線下滑的內存泄漏時，意外挖到一個很“冷門”的套路。
很多開發者在處理 WebSocket、setInterval 計時器，或是不會自己收尾的第三方庫時，都會撞上同樣的問題。我也經歷過：因為漏掉一個清理動作，看著本來順滑的界面逐漸變卡，這種無力感——太熟悉了。
今天一起過一套能解決99% 內存泄漏的實踐：這是不少專業團隊在用、卻很少系統寫下來的“統一清理策略”。
正在吞噬你應用的內存泄漏
設想一個場景：組件里訂閱了 WebSocket，設了幾個定時器，還掛了第三方分析 SDK。
一切都很順，直到用戶在頁面間來回切換；組件裝載—卸載重復發生，而后臺任務仍在偷偷運行，持續吃掉內存與 CPU。
接著你會見到這條經典警告：
Warning: Can’t perform a React state update on an unmounted component.
這基本就宣告：發生泄漏了。因此，我們需要一種既穩妥又易于復用的收尾方法。
AbortController：萬物可撤銷的“清理總開關”
在折騰 useEffect 的時候，我重新審視了 AbortController，然后它就成了我的新“必帶工具”。
多數人以為它只配合 fetch 用，其實幾乎所有異步/可訂閱操作都能用這把“信號”來管理和取消。
關鍵點在于：一個控制器，統籌多路清理——一次 abort()，多處收尾。
useEffect(() => {
const ctrl = new AbortController();
const { signal } = ctrl;
// WebSocket
const ws = new WebSocket('wss://api.example.com');
// 事件監聽：原生支持 signal 選項（現代瀏覽器）
const handleResize = () => { /* ... */ };
const handleEscape = (e) => { /* ... */ };
window.addEventListener('resize', handleResize, { signal });
document.addEventListener('keydown', handleEscape, { signal });
// 其它自定義清理項集中登記
const cleanups = [];
// 第三方庫
const analytics = new Analytics();
analytics.connect();
cleanups.push(() => analytics.disconnect());
// 定時器
const id = setInterval(updateData, 1000);
cleanups.push(() => clearInterval(id));
// 統一收尾
return () => {
ctrl.abort(); // 一鍵撤銷：事件監聽自動移除
ws.close(); // 關閉 WebSocket
cleanups.forEach(fn => fn()); // 執行自定義清理
};
}, []);妙處在于：一次 ctrl.abort() 就能讓帶 signal 的監聽器自動解除；因此，不必為每個 handler 手動 removeEventListener。與此同時，你還能把無法“自動撤銷”的資源統一登記，最后集中回收。
WebSocket 的“可驗證清理”寫法
WebSocket 極易在卸載后殘留回調、繼續觸發狀態更新。下面這段實踐非常耐用：
const useWebSocket = (url) => {
const [socket, setSocket] = React.useState(null);
const [messages, setMessages] = React.useState([]);
React.useEffect(() => {
const ws = new WebSocket(url);
const ctrl = new AbortController();
ws.onopen = () => {
console.log('WebSocket connected');
setSocket(ws);
};
ws.onmessage = (evt) => {
// 組件仍然“存活”才更新
if (!ctrl.signal.aborted) {
setMessages(prev => [...prev, JSON.parse(evt.data)]);
}
};
ws.onerror = (err) => {
console.error('WebSocket error:', err);
};
return () => {
ctrl.abort();
ws.close(1000, 'Component unmounting'); // 優雅關閉
setSocket(null);
};
}, [url]);
return { socket, messages };
};關鍵洞見：更新狀態前**檢查 ctrl.signal.aborted**。因此，卸載后的“過期回調”會被自然短路，告別那條煩人的警告。盡管如此，別忘了服務端也要容錯，避免頻繁斷連導致的反復重連。
計時器：用數組一次性回收
計時類任務也是泄漏高發區。管理多路 setInterval 的干凈寫法如下：
const useMultipleTimers = () => {
const [counts, setCounts] = React.useState({ fast: 0, slow: 0 });
React.useEffect(() => {
const timers = [];
// 快速計數
timers.push(
setInterval(() => {
setCounts(prev => ({ ...prev, fast: prev.fast + 1 }));
}, 100)
);
// 慢速計數
timers.push(
setInterval(() => {
setCounts(prev => ({ ...prev, slow: prev.slow + 1 }));
}, 1000)
);
// 統一清理
return () => {
timers.forEach(clearInterval);
};
}, []);
return counts;
};小技巧：把定時器 ID 放進一個容器，卸載時一網打盡；因此，越多的計時任務，越能體現這種寫法的可擴展性。
第三方庫訂閱：適配任何“可退訂”接口
很多庫會返回 subscription 或 unsubscribe 之類的句柄。我們可以把“訂閱—撤銷”與“存活檢查”統一起來：
const useThirdPartySubscription = (config) => {
const [data, setData] = React.useState(null);
const subRef = React.useRef(null);
React.useEffect(() => {
const ctrl = new AbortController();
let sub = null;
const setup = async () => {
try {
const lib = await import('some-analytics-lib');
sub = lib.subscribe(config, (next) => {
if (!ctrl.signal.aborted) {
setData(next);
}
});
subRef.current = sub;
} catch (e) {
console.error('Subscription setup failed:', e);
}
};
setup();
return () => {
ctrl.abort();
if (sub && typeof sub.unsubscribe === 'function') {
sub.unsubscribe();
}
subRef.current = null;
};
}, [config]);
return data;
};這在 Socket.IO、Firebase 等“訂閱型服務”上同樣好用；與此同時，你還能在 catch/finally 分支里保留容錯與重試策略。
進階：建立“清理注冊表”
當一個組件里有多條生命周期資源時，建立“注冊表”能把清理邏輯集中到一個出口，因此幾乎不可能漏項。
const useCleanupRegistry = () => {
const bucketRef = React.useRef([]);
const register = React.useCallback((fn) => {
if (typeof fn === 'function') bucketRef.current.push(fn);
}, []);
React.useEffect(() => {
return () => {
bucketRef.current.forEach(fn => {
try { fn(); } catch (e) { console.error('Cleanup failed:', e); }
});
bucketRef.current = [];
};
}, []);
return register;
};
// 使用示例
const MyComponent = () => {
const register = useCleanupRegistry();
React.useEffect(() => {
// WebSocket
const ws = new WebSocket('wss://api.example.com');
register(() => ws.close());
// Interval
const interval = setInterval(() => {/* ... */}, 1000);
register(() => clearInterval(interval));
// DOM 事件
const onClick = () => console.log('clicked');
document.addEventListener('click', onClick);
register(() => document.removeEventListener('click', onClick));
}, [register]);
return <div>Component content</div>;
};這種模式把“分散的清理點”抽象成“可登記的回調”，因此結構清晰；然而，請控制嵌套層級，避免過度包裝導致的可讀性下降。
現代 fetch 與 AbortController：所有狀態更新都先“問一嘴”
人人都該掌握的 fetch 清理范式如下。核心就是：**每一次狀態寫入之前，先檢查 aborted**。
const useFetchData = (url) => {
const [data, setData] = React.useState(null);
const [loading, setLoading] = React.useState(false);
const [error, setError] = React.useState(null);
React.useEffect(() => {
const ctrl = new AbortController();
setLoading(true);
setError(null);
fetch(url, { signal: ctrl.signal })
.then(res => res.json())
.then(json => {
if (!ctrl.signal.aborted) setData(json);
})
.catch(err => {
if (err.name !== 'AbortError' && !ctrl.signal.aborted) {
setError(err.message);
}
})
.finally(() => {
if (!ctrl.signal.aborted) setLoading(false);
});
return () => ctrl.abort();
}, [url]);
return { data, loading, error };
};因此，即使出現競態、慢請求或快速切頁，也不會把“過期結果”寫回已經卸載的組件；與此同時，錯誤分支也能保持干凈。
為什么這套能擋住 99% 的泄漏
基于 AbortController 的統一策略之所以有效，是因為它：
- 集中管理：一個控制器可統籌多路資源與事件；
- 阻斷陳舊更新：卸載后
signal.aborted讓過期回調自動失效； - 天然可擴展：新增任意異步源，只需登記清理或傳入同一
signal； - 覆蓋邊角：競態、快速切換與多訂閱并存時，依然能保持一致的收尾路徑。
簡潔之美正在于此：你無需逐條記住“第 N 個監聽要怎么解綁”，只要設好控制器 + 注冊表，其余交給機制自己協調。因此，整個團隊的認知負擔也明顯下降。
最后的要點
許多成熟團隊都在采用這套模式：它穩健、易維護，并且能讓復雜頁面在長時間使用后依舊清爽。 不妨在下一個需求里試試，然后告訴我你的體驗與改進建議；盡管如此，如果你在接入遺留 SDK 時遇到特殊清理邊界，也歡迎留言交流。
感謝閱讀。我們下次繼續聊一個更“好玩”的 React 小技巧。
