内存泄漏是该回收的对象因残留引用未释放，导致内存缓慢增长；内存溢出是申请内存时空间不足而直接报错中断。二者本质不同：泄漏偷时间，溢出撞墙；泄漏可能引发溢出，但溢出未必由泄漏引起。
内存泄漏和内存溢出不是同一类问题，区分关键在于：泄漏是“该收没收”，溢出是“要不到”。泄漏不一定会立刻崩溃，但会悄悄拖垮系统；溢出则是明确报错、直接中断。
本质区别：一个在偷时间，一个在撞墙
内存泄漏的本质是对象本该被回收，却因残留引用无法释放。比如一个已卸载的 React 组件，其内部定时器仍持有 DOM 节点或大数组，GC 就不敢动它——内存占用缓慢爬升，页面越来越卡，但还能用。
内存溢出的本质是申请新内存时，堆（或栈、元空间）已无可用空间。比如一次性 new 100 万个对象，或递归过深撑爆调用栈——JVM 直接抛 OutOfMemoryError 或浏览器弹 RangeError: Maximum call stack size exceeded，程序瞬间终止。
二者关系不是“等于”，而是“可能引发”：长期泄漏大概率导致溢出，但溢出也可能毫无泄漏——比如只运行一次的大文件解析，内存配得太小，一开就崩。
前端常见未释放变量场景与自查清单
这些变量最容易“赖着不走”，尤其在 SPA 中：
-
全局挂载的变量：未用
let/const声明，或在非严格模式下给window赋值（如data = [...bigArray]），这类变量生命周期等同页面，永不回收 -
定时器/事件监听器未清理：组件销毁后，
setInterval或addEventListener仍活跃，持续引用外部作用域里的数据 -
DOM 节点被 JS 变量强持有：节点已从 DOM 移除（
removeChild），但 JS 里还存着它的引用（如let node = document.getElementById('x')），节点及其子树全卡在内存里 - 闭包意外保留大对象：外层函数创建了大数组或大对象，内层返回函数虽未使用它，但闭包结构让整个作用域无法释放
-
第三方库回调未注销：比如地图 SDK 的
on('click', handler)没配对调用off，handler 又引用了组件实例，形成闭环持有
快速定位泄漏变量的实操步骤
不用等崩溃，现在就能查：
- 打开 Chrome DevTools → Memory 标签 → 点击 Record Allocation Timeline，操作疑似泄漏的流程（如进/出页面、开关弹窗），停止录制后观察蓝色条——持续增长且不回落的，就是新分配未回收的对象
- 切换到 Heap Snapshot → 先拍一张快照（Snapshot 1），做几次重复操作（如打开关闭同一模块），再拍一张（Snapshot 2），用 Comparison 视图筛选 Objects allocated between Snapshot 1 and Snapshot 2，重点看数量激增的构造函数（如
Array、Object、自定义类名） - 点击可疑构造函数 → 右侧查看 Retainers（持有者链），顺着箭头一路往上找，最终停在某个全局变量、定时器、事件监听器或闭包上——那就是泄漏源头
- 验证修复：删掉疑似代码（如加
clearInterval、置node = null），重跑流程，对比快照中对应对象数量是否不再累积
崩溃发生后，先别急着重启
如果已经 OOM 崩溃，优先确认是不是瞬时压力过大：
- 检查错误堆栈是否含
RangeError: Maximum call stack size exceeded（栈溢出，多为死递归）或AbortError（资源中断），而非Out of memory - 查看用户操作路径：是否刚上传了一个 500MB 文件？是否点了“全量导出”按钮？这类不是泄漏，是需求与配置不匹配
- 若确定是泄漏引发的溢出，回溯最近上线的模块，重点审查新增的全局缓存、长周期定时器、第三方 SDK 集成代码
不复杂但容易忽略
