JavaScript 在浏览器和 Node.js 中通常依赖垃圾回收机制自动管理内存，但自动并不等于绝对安全。大量页面在长时间运行后出现卡顿、响应变慢甚至崩溃，核心原因常常是某些变量或对象一直保持着引用关系，垃圾回收器无法判断它们已经不再需要。要真正防止内存泄漏，需要先理解引擎如何判断对象可回收，再在编码时主动切断不必要的引用。
理解垃圾回收与可达性判断
JavaScript 引擎最主流的垃圾回收算法是标记清除。其基本思路是：从根对象开始，标记所有可以通过引用链访问到的对象；回收阶段清除没有被标记的对象。根对象包括当前执行上下文中的局部变量、全局对象（浏览器中为 window）、闭包中仍被引用的变量等。一旦对象不再从根出发可达，理论上就可以被回收。
但可达性判断与变量是否仍被需要并不是同一个概念。一个典型的误区是认为只要不再调用某个函数，函数内部的变量就会被释放。实际上如果该函数创建了一个闭包，并把这个闭包保存到全局变量、DOM 属性或模块级变量中，闭包所捕获的外层变量就一直可达，直到外层引用被显式清除。现代引擎对闭包做了一些优化，只会保留闭包实际使用到的变量，但这并不能完全避免开发者无意识持有大对象。
引用计数算法曾是早期浏览器的实现方式，IE8 及更早版本在 DOM 和 JavaScript 对象之间通过引用计数管理内存，容易发生循环引用问题。比如一个 DOM 元素保存了一个 JavaScript 对象引用，而该 JavaScript 对象又反向保存 DOM 元素，即使页面移除元素，引用计数也不归零，导致无法释放。现代浏览器已经很少使用纯引用计数，但理解这一历史背景有助于明白为什么循环引用在早期前端代码中极容易引发泄漏。
六类常见内存泄漏场景与代码示例
1. 全局变量与未声明变量
在非严格模式下，未使用 var、let、const 声明的赋值会创建一个全局变量。例如在函数中直接写 data = largeArray，这个数组会挂到 window 上，除非手动删除，否则永远留在内存中。全局变量本身的生存周期就是整个应用生命周期，因此应该尽量减少全局变量，尤其是缓存大对象时。
function loadData() {
data = new Array(1000000).fill('x'); // 意外创建全局变量
}
如果需要临时保存计算结果，优先使用函数内部局部变量，并让变量在函数执行完毕后自然释放。对于确实需要跨模块共享的数据，也应设计明确的清理接口，而不是直接挂到全局对象上。
2. 定时器未清理
setInterval 和 setTimeout 在回调中若持有对页面对象或大量数据的引用，即使组件销毁，定时器仍然活动，引用也不会释放。应保存定时器 ID，在组件卸载或页面隐藏时调用 clearInterval 或 clearTimeout。
class DataFetcher {
constructor() {
this.timer = setInterval(() => {
this.poll();
}, 5000);
}
destroy() {
if (this.timer) {
clearInterval(this.timer);
this.timer = null;
}
}
}
单页应用中用户频繁切换路由时，如果定时器没有跟着销毁，就会出现多个定时器同时运行，不断请求数据或更新状态，加重内存和网络负担。把清理逻辑统一放在组件的销毁阶段，可以避免这一类问题。
3. 事件监听器未移除
在元素上调用 addEventListener 后，浏览器会通过事件目标保存回调函数引用。如果组件销毁时没有调用 removeEventListener，即使元素从页面移除，若还有其他地方引用该元素，监听器也无法被回收。尤其是在使用闭包回调时更容易放大泄漏。
// 错误示范
function bindResize() {
const handleResize = () => {
document.body.style.height = window.innerHeight + 'px';
};
window.addEventListener('resize', handleResize);
}
上面的代码每次执行都会新增一个监听器，却从未移除。更推荐的做法是在绑定监听器时保存引用，并在清理阶段调用 removeEventListener，或者使用 AbortController 统一管理。
4. 游离 DOM 引用
如果 JavaScript 变量保存了已经不在文档中的 DOM 节点，该节点虽然不渲染，但会作为 detached DOM 保留在堆内存中。常见于先把元素赋值给变量，再调用 removeChild 将其移出页面，但变量没有置空。更隐蔽的是在数组中缓存大量已移除元素，或者某个对象的属性保存了对子元素的引用。
let cachedElement = document.getElementById('oldPanel');
document.body.removeChild(cachedElement);
// cachedElement 仍引用已移除的元素
cachedElement = null;
这类问题在表格、列表或弹窗频繁增删的场景中尤为明显。如果一个已经关闭的弹窗仍然被模块级变量引用，其内部的输入状态、图片对象和事件系统都难以释放，因此移除 DOM 后应同步清空相关引用。
5. 闭包缓存大对象
闭包可以让函数访问外层作用域的变量，但如果闭包长期存在，外层的大数组、大对象也可能一直被保留。开发中容易出现的情况是：为了使用某个配置项而把整个响应数据包放进闭包，即使闭包只用其中一个字段，其他字段也无法及时释放。
解决方案是只将必要的数据放入闭包作用域，或者在缓存数据时直接提取标量值和小对象，避免把完整的响应体长期挂在内存中。对需要频繁读取的缓存，可以使用 WeakMap 关联对象标识与状态，在对象失去外部引用后自动释放。
6. 循环引用
虽然现代浏览器使用标记清除，单纯 JavaScript 对象之间的循环引用一般可以被回收，但 DOM 与 JavaScript 对象互相引用时，早期浏览器和某些宿主环境仍可能出现无法回收的情况。即使现代引擎可以处理，保持干净的对象引用仍然能降低内存峰值，并让代码更容易维护。
例如一个 DOM 元素通过属性保存了当前组件的实例，组件实例又保存了该 DOM 元素，移除元素后如果没有把属性置空，就可能出现引用残留。编写组件时应当避免在 DOM 节点上直接挂载复杂的对象引用，改用 WeakMap 或框架自带的实例管理机制。
从主动清理到弱引用工具的预防方案
防止内存泄漏的第一原则是明确资源归属和生命周期。谁创建了定时器、监听器、WebSocket 连接、Observable 订阅，谁就要在合适的时机释放。对于 UI 组件，可以利用框架的生命周期钩子，在组件销毁时统一清理。类组件和函数组件都应当把清理逻辑看作与初始化逻辑同等重要的一部分。
WeakMap 和 WeakSet 是专门用于存储弱引用对象的集合。它们的键必须是对象，且键的引用不影响垃圾回收。只要键对象在其他地方没有被引用，WeakMap 中的键值对会自动消失。因此在缓存数据与 DOM 元素关联时，使用 WeakMap 比 Map 更安全。
const domCache = new WeakMap();
function storeData(node, payload) {
domCache.set(node, payload);
}
function getStoredData(node) {
return domCache.get(node);
}
其他原生 API 也提供了自动清理机制。AbortController 可以同时取消 fetch 请求和移除事件监听器。例如给 addEventListener 传递一个 signal，当调用 abort 时，监听器会自动卸载，不需要手动 removeEventListener。
const controller = new AbortController();
function handleResize() {
console.log('resized');
}
function setup() {
window.addEventListener('resize', handleResize, {
signal: controller.signal
});
}
function teardown() {
controller.abort();
}
在一些现代框架和浏览器 API 中，弱引用、Signal、FinalizationRegistry 等机制可以进一步辅助资源回收。不过需要明确的是，这些机制并不能替代主动清理。只有当业务代码不再需要对象时，主动解除引用才是根本手段。
用开发者工具定位内存泄漏
Chrome DevTools 内存面板提供堆快照、时间轴上分配和分配采样三种模式。堆快照可以对比操作前后对象数量变化，重点关注 detached DOM 节点、闭包和事件监听器数量。时间轴上分配可以观察页面运行期间哪些函数持续分配内存，结合执行路径定位具体代码。
性能面板的录制结果能同时展示 JavaScript 堆大小、文档节点数量、监听器数量和帧率。若堆大小曲线呈锯齿状上升且回落幅度不足，说明可能存在内存泄漏。也可以在控制台使用 performance.memory 查看部分内存指标，但它只提供近似值，更适合快速确认趋势，精确定位仍要依赖堆快照。
常见排查思路是：加载页面后先记录一次堆快照，执行一段完整操作流程，再回到初始状态并手动触发垃圾回收（DevTools 内存面板中的垃圾桶图标），最后再记录一次快照。如果第二次快照中对象数量仍然明显高于第一次，说明操作过程中产生了无法释放的引用。可通过快照对比视图按构造器名称或距离根路径排序，找到异常对象后再回看代码引用关系。
工程化层面减少泄漏风险
在团队项目中，可以用 ESLint 规则限制意外全局变量、未处理的 setInterval 等。例如 no-undef、no-unused-vars 能减少意外赋值，而 React Hooks 中可使用 eslint-plugin-react-hooks 的 exhaustive-deps 规则辅助检查 useEffect 清理函数。TypeScript 的类型系统则可以在编译期发现可能的空值、未定义和资源未释放路径，但不能完全替代运行时内存管理。
对于 React 组件，useEffect 的返回函数是清理资源的标准位置。任何在 effect 中创建的定时器、事件监听、WebSocket 连接或订阅都应在返回函数中释放。Vue 的 onUnmounted 或 beforeUnmount 生命周期同样适合集中清理。若项目使用 RxJS，记得通过 takeUntil 或 subscription.unsubscribe 取消订阅，避免 Observable 在组件销毁后继续推送数据。
import { useEffect } from 'react';
function useWindowResize(handler) {
useEffect(() => {
window.addEventListener('resize', handler);
return () => {
window.removeEventListener('resize', handler);
};
}, [handler]);
}
此外，代码评审时也可以重点关注三件事：是否有全局缓存无限增长、是否有事件监听只添加不移除、是否有闭包持有超出需要的大对象。把内存泄漏排查纳入常规评审和测试流程，比等到线上出现性能问题再排查成本低得多。
JavaScript内存泄漏垃圾回收机制内存管理修改时间：2026-08-22 07:56:24