JavaScript内存泄漏的本质是本该不可达的对象因意外引用链保持可达性，导致GC无法回收；核心在于“谁持有引用？为何未断链？”，需紧扣标记清除原理，从定时器/事件监听器、意外全局变量、闭包不当保留大对象三类高频场景，以“现象→原理→解法”闭环讲透。
面试时讲内存泄漏，关键不是罗列所有情况，而是说清“为什么漏”和“怎么断链”。一句话点题：JavaScript 内存泄漏的本质，是本该不可达的对象，因为意外的引用链保持了可达性，导致垃圾回收器（GC）无法释放。
紧扣 GC 原理开场
一开口就锚定底层逻辑，比背场景更有说服力：
- JS 的 GC 主要靠标记清除（Mark-and-Sweep），从全局对象、当前执行上下文等根节点出发，标记所有可达对象；未被标记的才回收
- 所以泄漏 ≠ GC 失效，而是“不该被标记的对象，被某条隐含引用链悄悄连上了根”
- 回答时始终围绕“谁持有引用？引用为何没断？”来组织语言
挑 3 类高频场景讲透逻辑
不必全说，选最典型、最容易暴露理解深度的三类，每类用“现象→原理→解法”闭环：
- 未清理的定时器或事件监听器：比如组件挂载时 setTimer 或 addEventListener，但卸载时忘了 clearInterval / removeEventListener。回调函数闭包里常引用着组件状态或 DOM 节点，只要定时器/监听器活着，这些数据就一直可达
- 意外的全局变量：函数内漏写 let/const/var，或非严格模式下 this 指向 window，把大数组、大对象挂到全局。全局作用域生命周期 = 页面生命周期，等于长期持有所有引用
- 闭包不当保留大对象：函数返回闭包，而闭包又捕获了本该短命的大数据（如缓存、DOM 列表）。即使外层函数执行完，只要闭包还被外部变量持有，被捕获的数据就无法释放
带一个具体例子收尾
用一段简短可读的代码佐证，体现实操意识：
function loadData() {const bigData = new Array(1e5).fill('item');
return () => console.log(bigData.length); // 闭包捕获 bigData
}
const keeper = loadData(); // 此时 bigData 已无法回收
// ✅ 正确做法：只捕获必要值，或使用后主动置 null
keeper = null;
