🐛 问题场景

你大概率在项目里见过这个控制台警告：

Warning: Can't perform a React state update on an unmounted component.
This is a no-op,but it indicates a memory leak in your application.
To fix。cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

最常见的触发场景是这样的：

function UserProfile {
const = useState;useEffect => {
fetchUser.n => {
setUser;// ⚠️ 如果组件已卸载，这行报 warning
});},)，return 

{user?.name}
}

使用者快速切换页面时上一个 fetchUser 请求还没回来组件就已经卸载了。等 Promise resolve 后调用 setUser —— 警告出现。

痛点：你会在控制台看到一堆红色 warning。甚至出现页面卡顿、内存使用异常增长，却找不到根源。

🔍 原因分析

为什么卸载后还能 setState？

再看主要原因，异步操作的引用没有被清理。

抛出这个 warning。

真正的危害

实测：并发请求的列表页。如果每个卡片都发起请求且不做清理，切换页面后内存可能飙升至50 MB+。

💊 方法

再看方案一，useEffect cleanup

useEffect => {
let cancelled = false;fetchUser.n => {
if {
setUser;}
})，return => {
cancelled = true;// 组件卸载时标记取消
};},)，

• 优点：语义清晰，不引入额外依赖。 其实，
• 缺点：#每个异步操作都要写#cancelled#标记。稍显繁琐，说起来，

从方案二来看。AbortController

useEffect => {
const controller = new AbortController;fetchUser
.n => setUser)
.catch => {
if {
console.error;}
})，return => controller.abort;// 直接中断请求
},);

• 优点：true cancel HTTP 请求，省带宽、服务端资源。
• 缺点：#只对原生#fetch#有效，对自定义库需要适配。

从方案三来看，自定义 useSafeState Hook

function useSafeState {
const = useState;
const mountedRef = useRef;
useEffect => => { mountedRef.current = false;},)，const safeSetState = useCallback => {
if {
setState;}
},)，return;}
// 使用示例
const = useSafeState;fetchUser.n => safeSetUser);

• 优点：#一次封装，到处复用。
• 缺点：#全局替换#useState#成本较高，适合新项目或重构时引入。

🧪 实操验证

使用 React DevTools 的 Profiler 对比两种达到效果：

// ❌ 不做清理 — 快速切换页面后
// Heap snapshot 显示大量 detached fiber 和闭包
// Memory 面板能看到 "sizes" 继续增长
// ✅ 使用 AbortController — 快速切换页面后
// Network 面板看到请求自动 cancelled
// Memory 稳定无泄漏

Pain point check： 在你的项目里搜索 “#useEffect# + #n#” 的模式，大概率能抓出一批潜在泄漏点。每发现一个未清理的异步调用，都代表着一次可能导致使用者崩溃或卡顿的隐患。

📌 要点

1. S​React 的 warning 不容忽视：
2. S​单一职责原则：#useEffect# 只负责一件事，方便写正确的 cleanup。
3. S​AbortController 是 fetch 场景的最优解：
4. S​cancelled 标记法万金油：
5. S​React StrictMode 下更易暴露问题：