检测 javascript 中 set 的内存泄漏，核心在于确认 set 实例是否被全局变量或闭包意外持有，导致其中的对象无法被垃圾回收。排查时，应使用 chrome devtools 的 memory 面板进行 heap snapshot 对比，重点筛选 set 节点并检查其引用路径（retainers），若发现从 window 或全局作用域到目标 set 存在不可断开的引用链，即可判定为泄漏。
如何通过 Heap Snapshot 定位 Set 中的残留对象
在 Chrome DevTools 中，通过生成两次堆快照并对比差异，可以直观地看到 Set 中未被释放的对象。具体做法是：先触发可能产生泄漏的代码逻辑，拍摄第一次快照；然后手动触发垃圾回收（勾选 Collect garbage）并再次拍摄快照；最后在对比视图中搜索 Set 类型，查看 Shallow Size 和 Retained Size 的变化。如果第二次快照中 Set 的大小显著增加且未减少，说明其中的对象仍被引用。
const leakedSet = new Set();
function triggerLeak() {
// 模拟业务逻辑，将大对象加入 Set
const data = { id: Date.now(), payload: new Array(1000).fill('x') };
leakedSet.add(data);
}
// 执行多次以积累数据
for (let i = 0; i < 100; i++) {
triggerLeak();
}
上述代码中，leakedSet 作为全局变量，其引用的对象不会随函数执行结束而销毁。在 Memory 面板中，你可以看到 leakedSet 节点下挂载了 100 个 Object 节点，这些就是典型的 Set 泄漏证据。
立即学习“Java免费学习笔记（深入）”；
如何分析 Set 的 Retainer 引用链以找到泄漏源头
确定 Set 存在后，下一步是找出是谁持有了这个 Set。在 Heap Snapshot 中选中具体的 Set 节点，切换到 Summary 或 Comparison 视图，点击 Show paths to root 或查看 Retainers 标签页。这里会展示从根节点（如 <window></window>、<global></global> 或某个闭包环境）到该 Set 的所有引用路径。常见的泄漏源头包括：忘记清理的全局数组/Map/Set、DOM 元素的自定义属性绑定、或未解绑的事件监听器回调中捕获的局部变量。
// 修复示例：使用 WeakSet 或显式清理
const safeSet = new Set();
function processSafe() {
const tempData = { value: 'temporary' };
safeSet.add(tempData);
// 业务处理...
// 关键步骤：使用后显式删除
safeSet.delete(tempData);
if (safeSet.size === 0) {
// 可选：清空整个 Set 以防后续误用
safeSet.clear();
}
}
通过分析 Retainer，如果发现 leakedSet 直接挂在 Window 上，说明它是全局变量。解决方法是将其作用域限制在模块内，或在不再需要时调用 clear()。如果引用链经过一个 DOM 元素，检查是否在该元素上存储了 Set 引用，这会导致 DOM 无法卸载从而引发内存泄漏。
