大陆信使能做业务的前端不少，但提起“JS 垃圾回收”，大多数人的印象就是“后台自动处理，不用管”。我之前也是这么想的，直到有次排查一个后台管理页面的卡顿问题：页面开上半小时，切换几个菜单后内存从几十 MB 一路涨到 300 多 MB，点击响应越来越迟钝，用 Chrome 的 Memory 面板看，堆快照里挂着大量 Detached DOM 节点。那一刻我才意识到，垃圾回收机制不是面试八股，它直接决定你的页面在真实场景里会不会越用越卡、会不会崩。
这篇文章不打算讲成教科书式的 GC 讲义。我会从 V8 到底怎么判断“垃圾”、堆内存分成哪几块、回收算法如何演化，一直讲到闭包、事件监听、DOM 节点这些真实项目里最容易造成“永不回收对象”的场景，以及我实际用 Chrome DevTools、Node.js 排查内存问题的完整流程。无论你是写 React/Vue 的、做 Node 服务的，还是只写过几年业务代码，看完都能用得上。
1. 能被回收的从来不是“没用的变量”，而是不可达对象：GC 的定性逻辑
1.1 先纠正一个常见误解：变量不再被用到，不等于会被回收
很多初学者有个直觉：GC 会分析代码，发现某个变量后面的代码不再使用它，就把它回收。这是错的。JavaScript 引擎不是通过“未来会不会用到”来判断的，它是通过**可达性（reachability）**来判断的——现在这一刻，从程序的根节点出发，还能不能找到这个对象？找不到，它就随时会变成垃圾；找得到，哪怕你这辈子都不再读它，GC 也必须让它活着。
这么说有点抽象，我举个很反直觉的例子：
javascript复制function createReport() {
const hugeData = new Array(100000).fill({ type: 'history' });
return function showTip() {
console.log('报表生成成功');
};
}
const show = createReport();
hugeData 在 showTip 里压根没用过，看起来应该被回收了吧？其实不一定的。V8 在实现闭包时，如果内部函数引用了外层的某个变量，V8 会为它创建一个上下文对象，这个上下文可能把整个作用域里声明的变量都装进去。外部只要还持有 show 这个函数，show 就持有上下文对象，上下文对象又引用着 hugeData，那么这 100000 个对象就全部不可回收。这恰恰就是日常内存泄漏最常见的来源之一。
1.2 什么是根，什么是引用的传递路径
GC 要判断可达性，必须从一个确定的起点开始遍历。JavaScript 里的“根”（roots）大致包括：
- 全局对象，浏览器里是
window，Node.js 里是global； - 当前正在执行的函数栈里的局部变量、参数；
- 当前模块的顶层变量；
- 所有已经注册的事件监听器？严格说不是根，但如果它们能被根找到，最终会变成强引用；
- DOM 树中仍然挂载着根节点的元素。
引擎从这些根出发，沿着对象的属性、数组的元素、闭包的引用关系一路往下走。走到的对象就是“存活对象”，走不到的就可以回收。为了理解方便，可以把整块内存想象成一张有向图：对象是节点，属性引用是边。GC 不是统计“哪个变量没用了”，而是做一次从根出发的深度优先或广度优先遍历，看看哪些节点掉出了图外。
这个设计导致了一个重要结论：循环引用本身不会造成泄漏。
比如对象 A 引用 B，B 也引用 A，看起来互相救活，但只要外部没有任何路径能到达 A 或 B，它们就是整张图里孤立的两个点。GC 遍历时根本不会从任何根走进这个环里，所以它俩会被正确回收。也正因为这样，JavaScript 从来不需要像旧时代 IE 里 ActiveX 对象那样手动破环。
1.3 GC 不是定时器，它是被“分配压力”逼出来的
还有一点很容易踩坑：GC 并不像闹钟一样每隔几秒响一次。V8 的 GC 触发时机和内存分配强相关。当新生代空间被新对象占满时，会触发一次小的垃圾回收（Minor GC）；当老年代增长到一定阈值时，会触发一次完整的垃圾回收（Major GC）。
翻译成人话就是：你分配得越快、越猛，GC 就触发得越频繁。如果一个动画循环里每帧都创建大量对象，引擎可能每过几十帧就要停下来清理一次。而如果你写了一个越吃越大的全局缓存，老年代空间持续膨胀，最终触发 Major GC 时的停顿时间也会越来越长。
所以理解 GC 第一步不是背算法，而是把思维转过来：内存不是无限的池子，而是一块需要不断腾挪的共享空间。下一个章节，我来讲 V8 是怎么把这块空间分区管理、并利用不同策略优化回收效率的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. V8 把堆内存分成新生代、老年代以后，GC 局部分工才清晰起来
2.1 栈、堆和对象引用的三角关系
先做个非常基础的分工说明，后面所有分析都依赖这个模型。
JavaScript 里的基础类型（number、string、boolean、null、undefined、symbol、bigint 的一部分）大多存储在栈上，栈空间由函数调用和退出自动管理。对象、数组、函数、闭包上下文这些“大块头”，本体存在堆上。栈上保存的只是指向堆的引用地址。
看这段代码：
javascript复制function demo() {
const config = { theme: 'dark', items: [] }; // 堆上分配对象，config 变量在栈上保存引用
return config;
}
const globalConfig = demo();
demo() 执行结束后，栈上的 config 变量消失，但堆上的对象没有消失，因为全局变量 globalConfig 还持有指向它的引用。只要 globalConfig 不被覆盖，这个对象就永远可达。
所以排查内存问题时，真正值得关注的是“谁还握着引用”。这也是后面所有泄漏模式的底层原因。
2.2 新生代和 Scavenge 复制算法：短命对象的高效处理区
V8 把堆分成多个区域，最核心的两个是新生代（New Space）和老年代（Old Space），另外还有代码空间、大对象空间等。新生代又被分成两个半空间，通常叫 From-Space 和 To-Space。平时新分配的对象都放在 From-Space。
为什么要专门给新生代搞两个半区？因为 V8 观察到一个经验规律：绝大多数对象都是朝生夕死。你在一个函数里创建的临时数组、临时对象、中间计算结果，往往在函数返回后立刻失去引用。
新生代的回收算法叫 Scavenge，核心思路是“复制存活对象，而不是标记清理所有死对象”：
- 新生代里 From-Space 快满了，触发 Minor GC。
- 从根出发，遍历新生代里的对象引用图，把依然存活的对象复制到 To-Space。
- 整体清空 From-Space。
- 交换 From-Space 和 To-Space 的角色，下次分配继续在新的 From-Space 里进行。
这个算法对短命对象极其友好：因为大部分对象在第 2 步就死透了，根本不会被复制，清理动作只是把整个 From-Space 标记为空，效率很高。可以把它理解为餐馆里处理一次性餐具——多数餐具用一次就扔，不需要逐个清洗，直接把整桶倒了就行。
2.3 晋升：对象怎么被送进老年代
但不是所有对象都短命。如果一个对象连续活过了多次 Minor GC，V8 就会认为它是“长寿对象”，把它移动到老年代。这个过程叫晋升。晋升条件主要有两个：
- 对象经历过一次 Minor GC 后仍然存活；
- To-Space 的使用率超过一个阈值（通常是 25% 左右）时，V8 为了避免某个出生率极高的对象在 From/To 之间反复横跳，会直接把还活着的对象晋升到老年代。
老年代承载的对象生命周期很长，比如模块级别缓存、全局状态、DOM 树节点、被闭包长期引用的大数据对象。如果老年代以肉眼可见的速度持续变大，不用怀疑，你的代码里有什么东西正在被长期强引用。
有一类特殊情况：大对象不会放进新生代。V8 对超过一定大小的大块对象直接分配到大对象空间（Large Object Space），而且这部分空间通常不会移动——因为复制一个大对象成本太高。所以如果某段代码持续创建超大数组、超大字符串，它们会直接冲击老年代内存。
2.4 为什么要做分代：把有限的 GC 预算花在刀刃上
没有分代设计时，每次垃圾回收都得扫描全部堆对象。随着存活对象变多，GC 耗时线性增长，页面卡顿会越来越明显。分代方案的价值在于差异化处理：
- 新生代对象密度高、存活率低，适合用复制算法以空间换时间；
- 老年代对象存活率高，不适合反复复制，需要用标记-清除类算法原地处理；
- 不同生命周期对象的不同策略，让 GC 的整体成本大幅下降。
这个设计也解释了为什么排查内存问题时要关注“对象是否发生了晋升”。你本以为是临时数据，结果因为闭包或全局引用被长期持有，会被 V8 晋升到老年代，一旦晋升到老年代，清理起来就比重建一个新生代半空间复杂得多。后文我会讲到具体怎么观察这种现象。
3. 老年代的“老龄化清除”：从全停顿到并发标记，V8 做的交易
3.1 标记阶段：从根出发，把所有活对象标出来
新生代用 Scavenge 复制法，老年代不能照搬，因为老年代里长寿对象太多，复制成本高。V8 处理老年代用的是经典的标记-清除（Mark-Sweep），必要时再做标记-整理（Mark-Compact）。
标记阶段是基础。GC 会先从根节点出发，遍历所有可达对象，给每个对象打上“存活”的标记。这个遍历过程和第一章介绍的图遍历是同一件事，只是它发生在引擎内部。如果对象之间引用层级特别深——比如一个全局对象下面挂着几百个业务模块、每个模块又挂着缓存——标记的耗时就会非常可观。
标记阶段里有一个细节叫三色标记法：对象有白色、灰色、黑色三种状态。初始均为白色；被 GC 发现并放入待处理栈时变成灰色；等它的所有引用都被处理完毕，才变成黑色。黑色对象不会被再次访问，灰色对象仍在等待处理。这个机制是为了配合后面说的“增量标记”——如果只扫一次就完事，中间主线程没法插进来执行 JS 代码。
3.2 清除和整理：为什么会有内存碎片问题
标记完成后，没有被标记的对象就是垃圾。清除阶段负责把这些垃圾对象所在的内存块回收，归还给空闲列表。但问题来了：老年代的存活对象分布并不规律，回收掉中间几块后，剩余的内存会出现很多不连续的小空洞。下一次想分配一个较大的对象时，可能找不到连续的内存区域。这就是内存碎片。
碎片严重时，V8 会触发一次标记-整理：把所有还存活的对象往一端移动，让它们排列紧凑，消灭空洞。这个操作成本非常高，因为要搬运对象，还要修正一个又一个引用地址。所以 Mark-Compact 一般被当作“最后手段”，不会每次 GC 都触发。
这也能解释一个现象：一个页面开了很久以后，偶尔会突然卡一下。很可能就是老年代碎片积累到阈值，V8 被迫做了一次完整的整理。这次整理时主线程几乎被占用，页面交互自然就出现了一个明显的停顿。
3.3 别让主线程等太久：全停顿拆分成增量标记和并发清除
早期的 V8 GC 执行机制可以理解为“先暂停 JS 执行，一口气把 GC 做完，再恢复执行”，这叫全停顿（Stop The World）。当程序只跑几十秒、堆里没多少对象时没问题；可一旦碰到大型 SPA 或 Node 服务，堆内存动辄几百 MB，一次全停顿几百毫秒，用户就会明显感觉到页面卡一下。
为了降低停顿，V8 采取了一系列妥协策略：
- 增量标记：不一口气把所有对象都扫完，而是把标记过程拆成一个个小切片，穿插在主线程的 JS 执行之间。每执行一段 JS，就回来标记一小段。这样停顿被切得很碎，用户几乎感知不到。
- 并发标记：在后台线程上并行执行标记，主线程继续执行 JS，主要由辅助线程负责扫描对象图。标记结果再同步给主线程的 GC。
- 惰性清除和并发清除：清除操作不追求在标记之后立刻做完，可以延迟到需要分配内存时再顺手清理，同时也尽量在后台线程做。
这一系列演进背后的核心矛盾只有一个：GC 必须在牺牲一点回收实时性、和换取主线程流畅性之间做权衡。代价则是，GC 触发后对象不一定立刻被释放，内存用量在某个时间点会仍然偏高——所以不要用“看当前内存是不是下降了”来验证 GC 是否执行成功，而要看堆快照里的对象分布。
3.4 一个实验：在 Node 里观察 GC 事件
下面的命令不要求你执行，但可以帮助理解 GC 事件到底长什么样：
bash复制node --expose-gc --trace-gc -e "
const arr = [];
for (let i = 0; i < 500000; i++) {
arr.push({ id: i, data: new Array(100) });
if (i % 100000 === 0) {
console.log('before gc', process.memoryUsage().heapUsed);
global.gc();
console.log('after gc', process.memoryUsage().heapUsed);
}
}
"
--trace-gc 会输出每次 GC 的类型（Scavenge / Mark-Compact）、耗时和回收前后的堆大小。实验里你会看到：高频率分配对象会让 GC 被触发的次数明显变多，而如果这些对象还被 arr 持有，那么即使调用 global.gc()，heapUsed 也根本降不下来。这个现象是排查内存泄漏的试金石。
生产环境里不建议用 --expose-gc，也不建议在业务代码里手动调 global.gc()。它只是排查工具，不是性能优化手段。手动触发 GC 只能骗自己“内存降下来了”，真正要做的是找到仍然强引用对象的那条链路，让它不再可达。
4. 闭包、全局缓存和 Detached DOM：现场最容易漏的四类根因
4.1 闭包捕获整个上下文：变量变小胖整个作用域
前面已经举过 createReport 的例子，这里我再展开一下为什么会泄漏到老年代。
javascript复制function makeListener(itemId) {
const originalItem = loadLargeItem(itemId); // 假设这里拿了 10MB 数据
return function listener() {
const log = document.getElementById('log');
if (log) log.textContent = `item ${itemId} 已打开`;
};
}
const handlers = [];
for (let i = 0; i < 20; i++) {
handlers.push({ key: i, fn: makeListener(i) });
}
这段代码里，listener 内部只用了 itemId，但 V8 在实现闭包上下文时可能把 originalItem 也一起保留。更安全、也更清晰的写法是把真正需要的参数拆出来：
javascript复制function makeListener(itemId) {
return function listener() {
const log = document.getElementById('log');
if (log) log.textContent = `item ${itemId} 已打开`;
};
}
这样 listener 不会捕获那一整棵 10MB 的数据树。写代码时要形成一种直觉：一个被长期保留的函数，它闭包里的每个变量都会被长期保留。当你能确定某个大对象只用于前置初始化、而后续不需要时，可以考虑主动置空释放，但更好的做法是压根不让它进闭包。
4.2 全局变量和模块顶层变量：看似是临时数据，却被无意识保留
误用全局变量是经典中的经典。写业务代码时如果写掉了 a = data 这种不带声明关键字的赋值，非严格模式下会自动挂到全局对象上：
javascript复制function processResponse(res) {
lastResponse = res; // 忘了写 const/let，非严格模式挂到 window/global
}
更隐蔽的是模块顶层变量。很多同学把缓存、临时状态直接放在模块顶层：
javascript复制// cache.js
export const fullCache = [];
export function addToCache(item) {
fullCache.push(item);
}
单个模块生命周期等于整个应用生命周期。它本身不是错误，问题在于没有清空策略。应用切页、切换租户、重新拉数据后，fullCache 里的旧数据不会被 GC 收走，因为模块全局变量始终可达。如果这种缓存是持续追加的，就等于内存越吃越多。
处理方式主要有三种：限制数组长度、给每条数据加时间戳并定期淘汰、换成可手动清空的 Map 结构并在路由销毁时清理。具体选哪种取决于数据特性，但一定不能“只放不收”。
4.3 事件监听器、定时器和观察者：对象被回调悄悄兜住
事件监听器引起的泄漏是另一个重灾区。原因很简单：一旦某个对象被事件回调引用，而这个回调又被一个全局可触达的 emitter 或者 window 持有，那么这个对象就会一直活着。在 SPA 里频繁切换页面时，如果页面组件注册的回调没有在卸载时移除，就会累积出一堆“看不见的活动对象”。
典型场景：
javascript复制class Page {
constructor() {
this.chart = initChart();
window.addEventListener('resize', this.onResize.bind(this));
}
destroy() {
// 这里只做了销毁 DOM，没有移除 resize 监听
}
}
bind(this) 每次都会生成一个新的函数。如果你在 addEventListener 时 bind 了一次，销毁时又想用同一个函数去 removeEventListener，大概率会失败，因为你找不到当初那个绑定后的函数对象。这种情况就需要在构造时先把 bound 函数存下来，销毁时统一移除。
定时器同理：
javascript复制const timer = setInterval(() => {
fetchLog(); // 回调内部引用了这个页面模块里的状态
}, 5000);
如果一个页面在卸载时忘了 clearInterval，这个回调就会一直活着，回调闭包引用的所有对象也会一起活着。Node 服务里这个问题更隐蔽，因为 service 进程长期运行，每次请求注册的回调如果没被正确解绑，内存会一点一点积累，直到进程被 OOM 干掉。
4.4 Detached DOM Node：从文档流里移除，却还被人握着
这是浏览器端最有辨识度的泄漏类型，英文术语是 Detached DOM Node。它指的是：一个 DOM 元素已经从文档里 remove 了，div 在页面里看不见了，但 JS 代码里还有变量引用着它，于是这个元素本身、它的子树、绑定在它身上的事件监听器全部无法回收。
看个简化场景：
javascript复制const detachedBin = [];
function openModal(modal) {
detachedBin.push(modal);
}
function closeModal(modal) {
modal.remove();
}
很多框架在销毁 DOM 时不会自动清理所有外部引用，尤其是手写原生 JS 时。如果你把某个 DOM 节点塞进了全局数组或模块级 Set，又在某个操作里把它 remove 了，这个节点就成了“幽灵节点”。
判断这个类型的泄漏，Chrome DevTools 里的堆快照有专门的 Detached 筛选标签。点开之后能看到一长串 Detached HTMLDivElement、Detached HTMLLIElement，每个节点后面的 Retaining Path 可以直接告诉你是哪一行代码还引着它。后面第 6 章我会演示完整的排查路径。
4.5 无界缓存和无界 Map：缓存不设上限等于慢性泄漏
最后一个场景不是 bug，而是设计漏洞。缓存本身是合理的，但没有淘汰策略的缓存=慢性泄漏。典型例子：
javascript复制const detailCache = new Map();
async function openDetail(id) {
if (!detailCache.has(id)) {
const res = await fetch(`/api/detail/${id}`);
detailCache.set(id, res);
}
render(detailCache.get(id));
}
用户每打开一个新详情，detailCache 就多一条。如果详情页每天会被浏览几万次，这个 Map 就无限膨胀，所有缓存的对象无法被回收。这其实不能怪 GC——因为进程本来就认为你还需要这些 key，你 set 进去而不清理，在 GC 看来这就是合理的强引用。
给缓存加容量上限和过期时间是好习惯。现在很多业务场景其实可以直接用 WeakMap 来避免这个问题，下一章我会细说它的边界。
还有一个特别容易踩坑的组合：用 Map 或 Set 存储 DOM 节点。DOM 节点的生命周期通常由页面路由控制，但你把它们塞进了一个模块级 Set，如果不随节点移除清理，最终就会制造出大量 Detached DOM。改成 WeakSet 或者确保 remove 时同步 delete，可以省掉很多心智负担。
5. 配合 GC 的设计：WeakMap、WeakRef 与 FinalizationRegistry 的使用边界
5.1 WeakMap 的不漏原理：不干预 key 的生死，只帮 key 存元数据
WeakMap 和 Map 的最大区别是：WeakMap 对 key 是弱引用。也就是 WeakMap 本身的存在不会让 key 对象“变得可达”。一个对象如果除了 WeakMap 里的 key 之外没有任何强引用，那它随时可以被 GC 回收，同时它对应的 value 也会被清掉。
这个特性特别适合“边表”（side table）场景。比如业务里有一批接口返回的对象，你想给它们挂一个临时状态，但又不希望这个临时状态反过来拖住对象本身的生命周期：
javascript复制const itemState = new WeakMap();
function markSelected(item) {
itemState.set(item, { selected: true });
}
function isSelected(item) {
return itemState.get(item)?.selected ?? false;
}
列表页里每次从接口拿到新的 item 对象，渲染后打上选中标志。如果 item 不再被页面全局数组引用，WeakMap 不会阻止它被回收，自然也就不会发生泄漏。换作 Map，这些 item 即使页面已经销毁，也会因为 Map 强引用着 key 而一直存在。
5.2 WeakMap 和 WeakSet 的典型替换姿势
第一个替换场景是缓存与“身份数据”绑定。当你需要一个数据对象附加状态、但又不想写进对象自身时，优先 WeakMap。例如给 DOM 节点存元素的可见性状态、给组件实例存观察者列表。这里 WeakSet 更干脆：只需要判断“某个对象在不在集合里”时，WeakSet 不需要手动 delete，对象被 GC 后集合里的记录也会消失。
第二个替换场景是用模块级 Set/Map 存储随时可能销毁的外部实体。例如原来的 const activeSessions = new Set() 存 session 对象，如果 session 生命周期很短却不主动 delete，就会被 Set 无限强引用。换成 WeakSet 后，只要 session 在别处没有强引用，它自然离开集合。
需要说明的是 WeakMap 的函数名字 “Weak” 不代表“更快”。相反，由于弱引用追踪、以及键不能遍历等限制，WeakMap 适合特定场景，不意味着所有 Map 都要改。如果你的 key 对象本来就是生命周期和无界缓存绑定的，WeakMap 根本救不了你。比如：
javascript复制// key 是 URL 字符串，字符串不是对象，WeakMap 直接不能用
const cache = new WeakMap(); // TypeError: Invalid value used as weak map key
更常被误解的是：即使 WeakMap 的 key 是对象，只要 key 作为全局强引用长期存在，WeakMap 里的 value 也会一直存在。WeakMap 只是“不阻碍 key 被回收”，而不是“自动清理缓存”。在长期存活的 user 对象上放一个全量的用户详情缓存，GC 依然没法帮你清掉 value。所以无上限缓存问题的本质是设计，不是数据结构选择。
5.3 WeakRef 和 FinalizationRegistry：精确定位对象被回收的时机
ES2021 提供了 WeakRef，用来持有对象而不强引用它：
javascript复制const ref = new WeakRef(targetObject);
// 之后想用时：
const obj = ref.deref();
if (obj) {
// 对象还活着，正常使用
} else {
// 对象已经被 GC 回收了，需要重新创建或加载
}
WeakRef 不适合做高频主路径的数据结构。它的一个常见用途是做“可回收缓存”，但你要接受一个事实：对象随时可能被回收，下一次 deref 就返回 undefined。
FinalizationRegistry 提供了一个回调，用来感知对象被 GC 清理：
javascript复制const registry = new FinalizationRegistry((heldValue) => {
console.log(`${heldValue} 被回收了`);
});
let obj = {};
registry.register(obj, 'obj1');
obj = null;
这个工具最大的坑在于：回调时机既不及时也不确定。GC 不一定马上发生，回调依赖引擎的 GC 调度，所以绝不能拿它来释放关键的独占资源，比如文件句柄、WebSocket 连接，或者“必须在关闭前先登出”之类的状态。用它作为最后的兜底可以，把它当作正常清理逻辑不行。
我自己只用 FinalizationRegistry 做过一个低优先级的诊断：统计某个缓存对象被 GC 清掉了多少次，用来判断缓存命中率是否合理。真正紧耦合的资源，该手动 cancel 还是手动 cancel。
6. 一次实战复盘：反复进出详情页半小时后，页面卡到点不动
6.1 问题表现与初步判断
有一次接到线上反馈，说某个运营后台打开五六分钟后，鼠标操作开始掉帧，到后来一个按钮点下去要等两三秒才有反应。用户说“内存爆了”，其实并不准确。只看 Chrome 任务管理器里的内存，不能说没问题；真正要做的是看这个内存是“可回收”还是“不可回收”。
我让大家先在复现机里做同样的操作：不停进入列表页 → 打开详情 → 返回列表 → 再打开下一个详情，重复十次。然后我录了一条内存时间线。操作期间 JS 堆内存一路爬升，操作停止后我手动等到 GC 跑完，但内存只回落到一半，没有回到初始水位。这个“不回落的台阶”是相对可靠的泄漏信号。
6.2 Heap Snapshot 的对比法
Chrome DevTools 的 Memory 面板有几个选项，我推荐从 Heap snapshot 开始，操作成本最低。
做法：
- 进入页面，页面完全加载后，打第一份快照，标记为 Baseline。
- 执行一套固定操作（比如进出详情页 5 次）。
- 点 Memory 面板左上角的回收站图标，强制触发一次 GC。
- 等半分钟让页面稳定，打第二份快照。
- 再次执行同样操作，再打第三份快照。
如果第二份到第三份快照里的 detached 对象数量、总对象数量、retained size 还在明显上涨，说明每一次业务操作都会在堆里留下一些不可回收的残留。
光看总量还不够，因为有些对象虽然数量增长了，可能是因为新的缓存策略或者列表翻转。重点要看那类明确不该持续增长的：比如“关闭一个详情页后，详情页里的组件对象是否还在”，以及 “Detached HTMLDivElement” 这类名字极其直白的对象。
6.3 用 Retaining Path 找到那个偷偷留引用的地方
在 Heap Snapshot 的视图里，Classes 或者 Constructor 一栏输入 Detached，能看到一列 Detached 对象。随便点开一个，右侧的 Retainers 面板会展示从 GC 根到当前节点的完整引用路径，也就是什么对象还要用着它。
那次排查中，我最后点开一个 Detached HTMLDivElement，发现它的引用路径是：
code复制Window → 全局对象里的 openedCharts 数组 → chart container 对象 → 子节点 DOM
顺着代码找，发现是老代码在打开详情时把详情页容器 container push 进了一个全局的 openedCharts 数组，用来做“检查重复打开”的逻辑。关闭详情时把 DOM 从文档里 remove 了，但数组里还留着一个强引用，所以容器 DOM 树一直没被回收。系统跑久了之后，数组里攒了上百个详情 DOM，自然越来越卡。
修复很简单：关闭详情时从 openedCharts 里摘掉对应下标或改为 ID 记录，不要直接持有 DOM 节点。改完后重新走一遍 6.2 的操作流程，连续三份快照的 retained size 恢复到基本持平，问题解决。
6.4 Node.js 服务端的内存排查也可以复用同一套思路
Node.js 的内存问题和浏览器端类似，但少了 DOM 这个主角，多了一类叫 off-heap 的内存来源。排查时先区分：
process.memoryUsage().heapUsed持续上涨 → JS 对象层面问题。process.memoryUsage().rss持续上涨但 heapUsed 平稳 → 可能是有大量 Buffer、流、原生绑定之类的外部内存占用，这时堆快照不一定能直接看出问题，要排查 Node 里谁在分配 Buffer、谁没释放流。
想对 Node 进程里的 JS 堆做快照，可以用：
bash复制node --inspect server.js
然后打开 Chrome 地址栏输入 chrome://inspect，进入 Node 的调试面板，切到 Memory 标签页，就可以像调试浏览器页面一样录制 Node 堆快照。用这个方式抓过几次内存泄露，定位到的根因经常是模块级缓存、数据库查询结果缓存、或者 keep-alive 长连接回调闭包里的超大响应对象。
Node 端的复现操作通常更简单：选择一个测试接口，压测工具连续请求几万次，然后观察内存水位。如果请求结束后内存仍有大量不可回收对象，那就用堆快照对比请求前后的对象增长，按 retain size 排序，往往前几名就是泄漏点。
6.5 几个帮我少走弯路的排查习惯
排查内存问题最忌讳“凭直觉猜代码哪一行泄漏了”。我后来养成了一套固定动作：
- 每次操作路径必须固定，记录下操作次数，保证快照之间可对比。
- 确认堆快照前手动点一次回收按钮，但不要只依赖这一下。GC 是随机的，有些 WeakRef 或后台清理还需要时间，多等几秒再打快照更可靠。
- 大对象排序优先看 retained size 而不是 shallow size。一个对象本身不大，但它挂着整个子图，可能才是真正的内存大头。
- 把 “Detached DOM” 当成筛查关键词，而不是最终结论。真正要读的是 Retaining Path。
排查工具的最终目的不是告诉你“哪里内存高”，而是引导你去找到那条尚未断开的强引用链。一旦这条链断开了，GC 的功能才会发挥出来。
7. 写代码时如何给后续的 GC 少留点历史包袱
技术能力不只是能排查，更重要的是在代码层面提前避坑。我在实际开发中会强制自己带几个习惯，成本很低，但减少的内存问题相当可观。
第一是给生命周期明确的全局容器设置清理时机。模块级缓存一定要伴随“清空入口”：页面路由切换时、服务端请求结束时、轮询会话结束时，顺手把缓存容器 clear() 或者删除对应的 key。如果嫌每个业务模块都要写麻烦，就让缓存统一走一个带过期时间的封装。
第二是闭包函数不要随手捕获大对象。如果只是要输出一个状态或 ID，不需要把整棵列表塞进回调里。实在无法避免时，至少要意识到，这个函数每一次继续存在，那棵对象树也就会一直活着。
第三是注册事件监听器、定时器、观察者时，一定同步规划它们的解绑。我在 React 的 useEffect 里看到没有返回 cleanup 的 addEventListener 就会比较紧张，因为这种代码在组件卸载时真的会让子节点和回调闭包全部滞留堆中。
第四是强烈建议对 DOM 节点的“临时存储”使用 WeakMap/WeakSet 而不是 Map/Set。存储 DOM 节点或临时对象状态时，这几乎是最快降低残留的方案，代价只是你需要接受“key 不可枚举”这个限制。
有一次我把项目里的“已展开手风琴面板集合”从 Set 改成 WeakSet 后，路由切换几次再打堆快照，那批 Detached 节点就直接消失了。改造成本不过几行代码，收益却非常直观——你知道手风琴面板已经在页面里被移除了，但 GC 一直“觉得”你还留着它们，因为 Set 依然强引用着。类似这样的小数据结构选择，实际比你去钻研再深一层的 GC 回收参数更有用。
回到开头那个管理后台问题：最终修掉那条“全局 openedCharts 还持有 DOM 节点”的引用后，用户反馈说页面重开很长时间都不再卡顿。很多时候我们以为的“JS 垃圾回收机制不行”，其实只是某段代码里还留着一个看不见的强引用。把 GC 的判定逻辑弄明白，把堆快照的 Retaining Path 读顺，大多数内存问题都能在几分钟内找到根源。这也是我一直建议前端同学别只追新框架，而是先回头搞懂引擎为什么回收、以及如何配合回收的原因——它不会辜负你花下去的时间。