识别闭包导致的“幽灵状态”，关键在于发现那些本该随组件销毁而终止、却仍在后台执行的异步回调——它们像幽灵一样继续访问已失效的上下文（如 this、state、ref.current），轻则报错（如 “Cannot read property ‘setState’ of null”），重则造成内存泄漏或状态错乱。
识别闭包导致的“幽灵状态”，关键在于发现那些本该随组件销毁而终止、却仍在后台执行的异步回调——它们像幽灵一样继续访问已失效的上下文（如 this、state、ref.current），轻则报错（如 “cannot read property ‘setstate’ of null”），重则造成内存泄漏或状态错乱。
看异步回调是否捕获了组件实例或状态引用
典型信号：回调函数中直接使用 this（类组件）、setCount 或 inputRef.current（函数组件）等，且未做存活检查。
- 类组件中：
componentDidMount启动的fetch或setTimeout，回调里调用this.setState，但组件已在途中卸载 - 函数组件中：
useEffect内发起请求，回调里直接setLoading(false)或setData(res)，但组件已 unmount - 更隐蔽的是：回调里没调用状态更新，但引用了大对象（如
props.dataList或context.value），导致整个数据结构无法被 GC
查 DevTools 中的堆快照与 Retainer 链路
打开 Chrome Memory 面板 → 操作页面（进入/退出组件）→ Take Heap Snapshot → 筛选 Closure → 查找保留大小异常高、且关联到已销毁组件名的闭包。
- 重点关注
Retained Size大的闭包，点开看它的retainers - 若路径为
Closure → XHR/fetch callback → ComponentInstance → state/props，基本确认是幽灵回调在持有着组件 - 配合 Performance 面板录制，筛选
PromiseResolve或TimerFire事件，看是否有大量延迟触发的回调堆积
验 useEffect / useCallback 的依赖与清理逻辑
React 函数组件中最常见的幽灵来源，就是 useEffect 启动的异步任务缺少正确清理，或依赖数组写错导致闭包陈旧。
- 错误写法：
useEffect(() => { api.get().then(data => setData(data)) }, [])—— 回调闭包捕获了初始setData和data，后续状态更新无效；且无清理机制 - 正确做法：在
useEffect返回清理函数，内部用AbortController中断请求，或用标志位判断组件是否还“活着” - 进阶防护：用
useRef存一个布尔值isMounted，在回调开头加if (!isMounted.current) return
观察控制台错误与内存增长趋势
幽灵状态往往伴随两类可感知线索：
- 控制台频繁报
Can't perform a React state update on an unmounted component类警告（即使没崩溃，也说明回调在运行） - 反复进入/退出同一页面，
performance.memory.totalJSHeapSize持续上升，DOM 节点数不回落，Detached 节点增多 - 用
console.timeLog在异步回调开头打点，切换页面后仍看到日志输出，即证实幽灵存活
