内存泄漏侦探：用 FinalizationRegistry 抓捕 React 中的幽灵
各位好，欢迎来到今天的“内存地狱”巡演。
我是你们的特邀审计员，今天我们不讲那些花里胡哨的 CSS 动画，也不聊如何让你的按钮弹得像迪斯科球一样。今天我们要干一件更“硬核”的事——内存泄漏嗅探。
想象一下，你的 React 应用就像一辆法拉利。React 框架本身是引擎，写得很棒。但如果你在车里塞满了过期的罐头、没吃完的零食，甚至还在后备箱里养了一头大象，那这辆法拉利跑起来是什么感觉？对，你会觉得它越来越重，越来越慢，最后在红绿灯前彻底趴窝。
这就是内存泄漏。它悄无声息，像个穿着黑衣的刺客，在你毫无察觉的时候，慢慢吸干用户的设备电量。
React 告诉我们，组件卸载时要清理副作用。但真的清理干净了吗？浏览器告诉我们，垃圾回收器（GC）会自动清理。但 GC 是个沉默的寡言少语的家伙，它干活从来不吭声，而且有时候它还会偷懒，或者干脆因为内存不足而放弃清理。
今天，我们要给 React 加装一个“黑匣子”，利用 JavaScript 的高级特性——FinalizationRegistry，来监控组件卸载后，那些该死的资源到底有没有真正被释放。
准备好了吗？让我们开始这场寻尸之旅。
第一幕：GC 的沉默与我们的焦虑
首先，我们要搞清楚一个概念：垃圾回收。
在 JavaScript 中，内存管理是基于“引用”的。如果一个对象没有任何东西引用它，它就是垃圾。GC（垃圾回收器）的工作就是找到这些垃圾，把它们从内存里踢出去。
但是，GC 是什么时候工作的？你没法问它。你没法写 if (gc.isDone()) { ... }。它可能在页面空闲时工作，也可能在你疯狂点击按钮时工作。更糟糕的是，在现代浏览器中，为了性能，GC 可能会“延迟”释放内存，或者直接把内存保留在缓存中，以便下次复用。
这就导致了一个问题：你不知道你的组件真的卸载了，还是只是“假装”卸载了。
比如，你的组件里有一个 setInterval，每秒更新一次状态。当你卸载组件时，如果你忘了 clearInterval，这个定时器会一直运行下去，直到你关闭浏览器标签页。
React 的 useEffect 是我们的盾牌，但盾牌也有漏洞。如果我们忘记在返回函数中写清理逻辑，或者清理逻辑本身有 bug，那内存泄漏就会发生。
那么，如何验证我们的清理逻辑是否生效？
传统的办法是打开 Chrome DevTools 的 Memory 标签，录制堆快照，对比。这就像是在犯罪现场找指纹，既麻烦又不实时。
我们需要一个实时的、自动的、能够感知“对象死亡”的机制。这就是 FinalizationRegistry 登场的时候了。
第二幕：FinalizationRegistry —— 死后的信箱
FinalizationRegistry 是 JavaScript 引擎提供的一个 API，它的核心思想是：弱引用。
什么是弱引用？简单说，就是“我不该阻止你被垃圾回收”。当你创建一个对象并把它注册到 FinalizationRegistry 时，你传递了一个“held value”（持有值）和一个 target（目标对象）。
这个目标对象被注册时，并不会阻止 GC 回收它。GC 回收了它，并且觉得“哦，这玩意儿没用了，删了吧”，这时候，FinalizationRegistry 的回调函数就会被触发。
这就像是你给一个死去的人寄了一封信。你不需要一直守着他的坟墓，只要你把信寄出去（注册），等他入土为安（GC 回收）后，邮局（浏览器引擎）就会把信送给你。
关键点： 这不是 Promise，你不能 .then()。这是一个异步的、不确定的回调。你可能会立即收到信，也可能永远收不到（比如内存不足时，GC 可能会跳过 FinalizationRegistry 的回调以节省资源）。
所以，我们用它来做嗅探，而不是做绝对保证。
第三幕：实战 —— 打造一个 React 内存嗅探器
好，理论讲完了，我们开始写代码。
我们要构建一个通用的 Hook，叫做 useMemoryLeakSniffer。它的任务是：当组件卸载时，如果组件里有不该存在的“僵尸对象”，我们要能听到它的哀嚎。
1. 基础版：监控组件实例的死亡
首先，我们来看看如何监控一个普通对象。
// leak-sensor.tsx
import { useEffect, useRef } from 'react';
// 全局的注册表
const leakRegistry = new FinalizationRegistry((heldValue) => {
console.log('🔥 [MEMORY SNIFFER] 组件已销毁，但资源可能未释放！');
console.log(' -> 持有的值:', heldValue);
console.log(' -> 这是一个警告信号，请检查是否正确调用了清理函数。');
});
export const MemoryLeakSniffer = ({ children }: { children: React.ReactNode }) => {
useEffect(() => {
// 假设我们有一个组件实例对象
const componentInstance = {
id: Math.random().toString(36).substr(2, 9),
name: 'LeakingComponent',
// 这里可以模拟组件内部的资源
resource: new Array(1024 * 1024).fill('data'), // 1MB 的假数据
};
// 注册到 FinalizationRegistry
// heldValue 可以是我们需要的任何信息，比如组件名
leakRegistry.register(componentInstance, componentInstance.name);
// 模拟组件卸载
return () => {
console.log('🛑 组件卸载逻辑执行中...');
// 在这里，我们通常应该清理资源
// 如果我们忘记了清理，下面的代码虽然执行了，但对象可能已经被标记为垃圾
// 但是，因为我们已经 register 了，只要对象被回收，回调就会触发
// 这里我们故意不清理 componentInstance，看看会发生什么
// leakRegistry.unregister(componentInstance); // 如果你取消注释这行，警告就不会出现
};
}, []);
return <>{children}</>;
};运行结果预测：
当你卸载这个组件时，控制台会打印出那行红色的警告。这意味着，尽管 React 告诉我们“组件卸载了”，但那个包含 1MB 数据的对象并没有立即消失，它还在内存里游荡。
但是等等，这看起来有点奇怪。 我们在 useEffect 的 return 里面写了清理逻辑（虽然没清理资源），React 会确保这个清理函数执行。为什么对象还没死？
这是因为 FinalizationRegistry 是异步的。即使你在 return 里销毁了引用，对象可能还在等待 GC 的下一次巡视。而且，如果你在清理函数里只是把变量置空了，但组件实例对象本身（那个大数组）可能因为某种引用链还在（虽然在这个例子里应该没了）。
这个例子只是个热身。真正的战场在于外部资源，比如 Web Workers。
第四幕：Web Workers 的坟墓 —— 终极挑战
Web Workers 是内存泄漏的重灾区。因为它们运行在独立的线程中，React 的生命周期管理对它们来说是盲区。如果你创建了一个 Worker，然后在组件卸载时忘了 terminate()，这个 Worker 会一直占用 CPU 和内存，直到页面崩溃。
让我们来抓捕一个“僵尸 Worker”。
// worker-sensor.tsx
import { useEffect, useRef } from 'react';
// 我们需要创建一个 Worker 的 URL
const workerCode = `
self.onmessage = function() {
// 模拟一个无限循环，吃掉 CPU
while(true) {
// 做点无意义的工作
}
};
`;
const blob = new Blob([workerCode], { type: 'application/javascript' });
const workerUrl = URL.createObjectURL(blob);
export const WorkerLeakSensor = () => {
const workerRef = useRef<Worker | null>(null);
const workerIdRef = useRef<string>('');
useEffect(() => {
console.log('👷 创建 Worker...');
const worker = new Worker(workerUrl);
workerRef.current = worker;
workerIdRef.current = `worker-${Date.now()}`;
// 注册这个 Worker 到我们的嗅探器
// heldValue: 组件名，方便定位
leakRegistry.register(worker, workerIdRef.current);
// 模拟组件卸载
return () => {
console.log('🧹 组件卸载，准备清理 Worker...');
// ⚠️ 危险区：如果你忘记下面这行代码，Worker 就会变成僵尸！
// worker.terminate();
};
}, []);
return (
<div>
<p>这是一个会泄漏内存的组件。</p>
<button onClick={() => alert('组件已卸载，但 Worker 还活着！')}>
卸载组件（不调用 terminate）
</button>
</div>
);
};测试这个组件：
- 点击按钮卸载组件。
- 打开 Chrome DevTools -> Performance -> Memory。
- 点击“Take Heap Snapshot”。
- 你会发现，那个 Worker 对象还在堆中。
- 现在，回到代码，加上
worker.terminate()。 - 再次点击卸载，再次截图。
- 奇迹发生了：那个 Worker 对象消失了。
但是，我们怎么用代码自动验证这个消失的过程呢？
我们需要一个“死亡日志”。
// 修改 leakRegistry
const deathLog = {
entries: [] as string[],
log(message: string) {
this.entries.push(message);
console.log(`💀 [DEATH LOG] ${message}`);
},
clear() {
this.entries = [];
}
};
// 修改注册表回调
const leakRegistry = new FinalizationRegistry((heldValue) => {
// heldValue 是我们传入的 workerId
deathLog.log(`对象 [${heldValue}] 被垃圾回收了！`);
});
// 在 WorkerLeakSensor 的 return 里
return () => {
console.log('🧹 组件卸载，准备清理 Worker...');
if (workerRef.current) {
workerRef.current.terminate();
// terminate 后，Worker 对象就没有引用了
// 等待 GC，我们的 FinalizationRegistry 就会收到通知
}
};逻辑闭环：
当你卸载组件并调用 terminate() 后，Worker 对象失去了所有引用。稍等片刻（或者强制 GC），deathLog 就会记录下“对象被垃圾回收了”。这证明我们的清理逻辑生效了，没有留下僵尸。
第五幕：深入 React 渲染管线 —— 时机就是一切
React 的渲染管线是一个复杂的流水线。useEffect 在渲染周期的末尾运行。
这就引出了一个微妙的问题：注册时机。
你不能在组件的渲染阶段（render）去注册 FinalizationRegistry，因为那时候组件实例还没完全挂载好，或者引用可能不稳定。而且，如果你在渲染阶段注册了一个组件实例，而组件实例在渲染期间就被销毁了（这在 React 中很少见，但在某些极端情况下会发生），你就注册了一个已经死掉的对象。
最佳实践是：在 useEffect 的挂载阶段（第一次执行）注册，在卸载阶段（return 函数）注销。
等等，注销？FinalizationRegistry 有 unregister 方法。
是的，如果你确定资源已经释放，并且你不希望收到回调，你可以注销。但在内存嗅探的场景下，我们通常不注销，我们希望它“活着”，直到被 GC 收走，这样我们才能听到“死讯”。
但是，有一个巨大的陷阱。
陷阱： FinalizationRegistry 的回调是在垃圾回收期间触发的。而垃圾回收期间，JavaScript 引擎的运行速度会显著变慢。如果你在一个高频调用的组件里注册了太多对象，可能会导致页面卡顿。
所以，我们的嗅探器应该是一个轻量级的工具，或者只在调试模式下启用。
第六幕：构建一个完整的监控 Hook
让我们把上面的逻辑封装成一个可复用的 Hook。这个 Hook 不仅能监控 Worker，还能监控任何你不想让它死掉的“对象”。
// useResourceMonitor.ts
import { useEffect, useRef } from 'react';
// 定义监控的数据结构
interface MonitorData {
id: string;
type: string; // 'Worker' | 'Interval' | 'Subscription' | 'Custom'
timestamp: number;
resource: unknown;
}
// 全局单例，保证即使组件卸载，注册表依然存在
const globalRegistry = new FinalizationRegistry((heldValue: MonitorData) => {
console.warn(
`%c[MEMORY LEAK DETECTED]`,
'background: #ff0000; color: #fff; font-weight: bold; padding: 4px;',
`资源 [${heldValue.type}] (ID: ${heldValue.id}) 已被 GC 回收！`,
`这意味着组件可能已经卸载，但该资源没有被正确清理。`
);
});
export const useResourceMonitor = <T extends object>(
resource: T,
type: string,
name: string
) => {
const monitorId = useRef<string>(`res-${Math.random().toString(36).substr(2, 9)}`);
useEffect(() => {
// 注册资源
// 我们传递 resource 对象本身作为 heldValue 的 key (或者传 ID)
// 注意：这里我们传递的是对象引用，但 Registry 只持有弱引用，不会阻止 GC
globalRegistry.register(resource, {
id: monitorId.current,
type,
name,
timestamp: Date.now(),
resource // 这里实际上并没有真正强引用，因为 Registry 内部机制
} as MonitorData);
// 监控返回值
return () => {
// 这里我们通常不知道 resource 是否已经被清理了
// 如果我们手动清理了（比如 worker.terminate），那么 resource 引用就断了
// 如果我们忘了清理，resource 引用还在组件作用域里，但可能在外部被断开
};
}, [resource, type, name]);
return monitorId.current;
};使用示例：
// 组件中使用
export const DemoComponent = () => {
const worker = useRef<Worker | null>(null);
const workerId = useResourceMonitor(
worker.current, // 传入 worker 实例
'WebWorker',
'DataProcessor'
);
useEffect(() => {
worker.current = new Worker(workerUrl);
// ... 监听消息 ...
return () => {
// 如果这里没写 terminate，worker.current 依然存在，但 useEffect 的闭包会变化
// 关键是：Worker 对象本身还在吗？
// 如果没有其他地方引用 Worker，它应该被回收
// 但是！因为 worker.current 在闭包里，组件卸载时闭包还在吗？
// 等等，这是一个常见的误区。
// useEffect 的 cleanup 函数在组件卸载时执行。
// cleanup 执行时，组件的 state 和 ref 还在吗？还在。
// 所以 worker.current 还在引用着 Worker。
// 只要 worker.current 还在，Worker 就不会被 GC。
};
}, []);
// 强制让 worker.current 为 null，模拟清理
const forceKill = () => {
if (worker.current) {
worker.current.terminate();
worker.current = null; // 断开引用
}
};
return (
<button onClick={forceKill}>Kill Worker (Clean up)</button>
);
};等等，这里有个大坑！
上面的代码有个逻辑漏洞。在 useEffect 的 cleanup 函数里，我们通常执行清理操作。如果我们执行了 worker.current = null，那么 Worker 对象就真的没有引用了。此时，GC 就会回收它，FinalizationRegistry 的回调就会触发。
所以，这个 Hook 实际上是在验证清理逻辑是否正确地断开了引用。
如果我们在 cleanup 里写了 worker.terminate() 但没有写 worker.current = null（这在 React Hook 闭包中比较难办，因为闭包会捕获旧的引用），那么 Worker 对象依然存活。
结论： FinalizationRegistry 是一个验证器。它告诉我们：“嘿，我看不到任何东西引用这个 Worker 了，GC 已经把它扔进垃圾桶了。”
第七幕：更复杂的场景 —— 事件监听器
除了 Worker，事件监听器也是大头。
export const EventListenerLeak = () => {
const containerRef = useRef<HTMLDivElement>(null);
useEffect(() => {
if (!containerRef.current) return;
const el = containerRef.current;
// 添加监听器
const handleResize = () => console.log('Resized');
el.addEventListener('resize', handleResize);
// 注册这个监听器对象（或者 el 本身）
// 注意：我们实际上监听的是 el，如果 el 被移除 DOM，事件可能还在
useResourceMonitor(el, 'EventListener', 'WindowResize');
return () => {
// 危险！如果这里漏了 removeEventListener，事件就会一直留在 el 上
el.removeEventListener('resize', handleResize);
};
}, []);
return <div ref={containerRef} style={{ width: '100px', height: '100px', background: 'red' }} />;
};在这个例子里，如果我们忘了 removeEventListener，el 节点虽然从 DOM 移除了，但 el 对象本身（以及它上面的 resize 事件属性）可能还在内存里，直到 GC。FinalizationRegistry 会捕获到 el 的死亡，并提示我们：“这个 DOM 节点死了，但它的死因很可疑，好像是被‘resize’事件给缠住了。”
第八幕：物理内存释放 —— 真的释放了吗？
这是最有趣，也最令人困惑的部分。
FinalizationRegistry 告诉我们：JS 对象引用被清除了。
这等于说物理内存被释放了吗？
不一定。这就是浏览器的内存管理机制。
当你创建一个大数组或一个 Worker，然后销毁它。浏览器可能会把这块内存标记为“可回收”，但它不一定立即归还给操作系统（OS）。浏览器会保留这块内存，以便下次创建新对象时直接复用，从而减少内存分配的开销。
这就好比酒店退房了，但你的行李还在客房里，酒店经理说：“没事，这房间我留着，下次有客人直接住这儿，不用打扫了。”
所以，FinalizationRegistry 检测到的是“逻辑上的释放”，这通常意味着“物理内存即将释放”或者“物理内存被缓存了”。
如果你想验证物理内存是否真的降下来了，你需要用 Chrome 的 Memory 工具做堆快照对比，或者用 DevTools 的 Memory Timeline 录制内存曲线。FinalizationRegistry 更适合做代码级别的验证，而不是系统级别的监控。
第九幕：终极代码 —— React Profiler 与 FinalizationRegistry 的联姻
既然 React 有 Profiler，为什么不把 FinalizationRegistry 嵌入进去，让它成为 Profiler 的一部分呢？
我们可以创建一个 HOC (Higher Order Component) 或者一个 Context Provider，在应用的最顶层注册所有组件实例。
// React Profiler + FinalizationRegistry 集成
import { Profiler, useState } from 'react';
const onRenderCallback = (
id: string,
phase: 'mount' | 'update' | 'nested-mount',
actualDuration: number,
baseDuration: number,
startTime: number,
commitTime: number,
interactions: unknown
) => {
// 这里可以记录渲染时间
};
const LeakGuard = ({ children }: { children: React.ReactNode }) => {
const [rootId] = useState(() => `root-${Math.random()}`);
return (
<Profiler id="LeakGuard" onRender={onRenderCallback}>
<MemoryLeakSniffer>{children}</MemoryLeakSniffer>
</Profiler>
);
};这样，每一次渲染和卸载，都会被 Profiler 记录。如果我们在 MemoryLeakSniffer 中配合 FinalizationRegistry，我们就能得到一个完整的生命周期图。
Profiler说：组件 Mount 了。FinalizationRegistry说：组件 Unmount 了（并检测到引用丢失）。- 如果两者时间差很大，或者
FinalizationRegistry没有触发，那就是泄漏。
第十幕：总结与警告
各位，我们今天聊了很多。FinalizationRegistry 是一个强大的工具，但它不是银弹。
它的优点：
- 异步监听：能听到对象死亡的消息。
- 弱引用：不会干扰正常的垃圾回收。
- 调试利器：能帮你发现那些“忘记清理”的副作用。
它的缺点：
- 不可靠：浏览器可能会为了性能不执行回调。
- 时机滞后：GC 回收是不确定的，回调可能几秒后才来。
- 只能监控引用：它不能强制你清理内存，它只是告诉你“嘿，没人引用这个了”。
最佳实践：
永远不要依赖 FinalizationRegistry 来保证你的应用不会崩溃。它只是一个哨兵。
你应该怎么做？
- 在
useEffect的 cleanup 函数中，显式地释放所有资源（clearInterval,removeEventListener,terminate）。 - 在你的代码里，加上
FinalizationRegistry的监控代码。 - 当
FinalizationRegistry触发回调时，不要惊慌。先检查你的 cleanup 函数是否执行了。如果执行了还没触发，那说明 GC 没来得及跑。 - 如果没执行 cleanup 就触发了回调，恭喜你，你抓到了一个幽灵！
内存管理是一场战争，React 提供了盾牌（Hooks），FinalizationRegistry 提供了望远镜。用它们，保护好你的应用，别让它变成一个内存黑洞。
好了，今天的讲座就到这里。现在，去检查你的代码，看看有没有哪个 Worker 正在角落里孤独地运行着吧！