排查 javascript 内存泄漏时，使用 console.count() 的核心方法是统计特定代码块或对象的创建次数，通过观察计数是否随预期不符持续增长来定位泄漏源。具体做法是在疑似产生新对象、闭包或事件监听器的位置插入 console.count('label')，并在控制台对比不同时间点的计数值。如果计数在页面刷新或组件卸载后依然增加，说明存在未清理的引用导致内存无法释放。
如何统计全局变量和对象实例的数量
要统计全局变量和对象实例的数量，需要在声明或实例化关键对象的地方调用 console.count()。例如，在一个单页应用中，如果每个路由切换都会创建新的 DOM 元素或数据模型，可以在构造函数或工厂函数中加入计数逻辑。通过在控制台查看带有特定标签的计数输出，开发者可以直观地看到这些对象被创建了多少次。如果应用设计为只应存在一个实例，但计数持续增加，则表明发生了泄漏。
let instanceCount = 0;
class DataModel {
constructor(id) {
this.id = id;
instanceCount++;
console.count('DataModel Instances');
}
}
// 模拟多次创建
new DataModel(1);
new DataModel(2);
new DataModel(3);
如何检测事件监听器是否被重复添加
检测事件监听器是否被重复添加，可以在绑定事件的回调函数或绑定逻辑处使用 console.count()。许多内存泄漏源于在循环渲染或频繁触发的生命周期中反复调用 addEventListener 而未移除旧监听器。通过在绑定处设置计数器，可以监控监听器的注册频率。如果计数增长速度快于用户交互或页面更新的频率，或者在页面导航后计数仍在增加，就极有可能是因为监听器未被正确移除导致的内存泄漏。
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
立即学习“Java免费学习笔记（深入）”；
function setupEventListeners() {
const btn = document.getElementById('myButton');
// 每次调用都增加计数，若此函数被多次调用且未清理，则泄漏
console.count('Event Listener Added');
btn.addEventListener('click', () => {
console.log('Clicked');
});
}
setupEventListeners();
setupEventListeners();
setupEventListeners();
基于 console.count 输出判断泄漏的具体条件
基于 console.count 的输出判断泄漏的具体条件是：当页面状态重置（如路由跳转、组件卸载）后，相关计数器的值没有停止增长，或者在垃圾回收（GC）后，堆内存快照中对应对象的数量与计数器的增量不一致。例如，如果 DataModel Instances 的计数显示创建了 100 个实例，但在 GC 后 Chrome DevTools 的 Memory Tab 中仍保留大量 DataModel 对象，且这些对象持有对已销毁 DOM 或数据的引用，即可确认为内存泄漏。此时需要检查是否有全局数组、闭包或定时器意外保留了这些对象的引用。
