JavaScript内存泄漏是长期运行后内存持续上涨导致卡顿或崩溃的问题，主因包括闭包意外保留DOM引用、未清除定时器、console.log强引用等，需主动管理引用生命周期。
JavaScript 中的内存泄漏不是“写错语法”那种立刻报错的问题，而是长期运行后内存占用持续上涨、页面变卡、甚至崩溃——它往往在你没察觉时已经发生。
闭包中意外保留 DOM 引用
闭包本身不导致泄漏，但若闭包内引用了本该被回收的 DOM 节点，而该闭包又被全局变量或长生命周期对象（如事件监听器、定时器）持有，节点就无法释放。
常见场景：为某个按钮绑定点击事件，回调里用了闭包捕获了整个父容器 container，之后又动态移除了该按钮，但监听器没解绑。
- 始终在组件卸载、元素移除前调用
removeEventListener - 避免在闭包中直接引用大型 DOM 树；如只需 ID 或文本，只存
element.id或element.textContent - 使用弱引用替代强引用：例如用
WeakMap存储与 DOM 元素关联的状态，而不是挂在element.myData = {...}上
定时器未清除（setInterval / setTimeout）
忘记清除定时器是最隐蔽的泄漏源之一。尤其在单页应用中，组件销毁后，其内部启动的 setInterval 仍持续执行，并持续持有对组件作用域内变量的引用。
立即学习“Java免费学习笔记（深入）”；
错误示例：const timer = setInterval(() => console.log(data), 1000)，但没配对调用 clearInterval(timer)。
- 把定时器 ID 存在可追踪的位置（如类实例字段
this._pollTimer），并在退出逻辑中统一清理 - 在 React 中，用
useEffect的清理函数；在 Vue 中，用onBeforeUnmount；纯 JS 则确保有明确的 “destroy” 或 “teardown” 调用点 - 避免在定时器回调中直接访问已可能被销毁的上下文对象，可加一层存在性检查：
if (!this.isAlive) return
console.log 在开发中也可能拖垮生产环境
这常被忽略：Chrome DevTools 开着时，console.log(obj) 会保持对 obj 的强引用（尤其在对象被展开查看后），阻止 GC 回收。线上虽无 DevTools，但某些日志 SDK 或调试工具也会做类似事。
- 上线前务必移除所有非必要
console.*调用，或用构建工具（如 webpack 的DefinePlugin）自动剥离 - 不要
console.log大型数据结构（如整个响应体、DOM 树、Canvas 对象）；改用console.table或提取关键字段打印 - 警惕第三方日志库的“自动序列化”行为——有些会深遍历对象并缓存引用，需查阅其文档确认是否启用
weakRef或限制深度
真正难排查的泄漏，往往藏在“看起来没问题”的组合里：一个没清理的事件监听器 + 一个带闭包的回调 + 一次 console.log 查看 —— 三者叠加，就足以让某个组件实例永远驻留内存。别依赖“应该会被回收”，主动管理引用生命周期才是关键。
