基本类型不会内存泄漏，因其存储在栈中、生命周期由执行上下文严格控制，函数结束即自动销毁；真正引发泄漏的是堆中的引用类型，如object、array等被意外长期持有而阻断gc回收。
内存泄漏排查中，区分基本类型和引用类型是关键起点——因为只有引用类型才可能引发泄漏，而基本类型根本不会。
为什么基本类型不会泄漏
JavaScript 中的 String、Number、Boolean、null、undefined、Symbol、BigInt 这些基本类型存储在栈内存里，生命周期由执行上下文严格控制。函数执行结束，栈帧销毁，它们自动消失，不参与垃圾回收判定，也不存在“被意外持有”的风险。
真正需要警惕的是堆内存中的引用类型：Object、Array、Function、Map、Set、RegExp、Date 等。它们一旦被意外长期持有，就可能阻断 GC 回收路径。
引用类型泄漏的典型模式
以下几种情况最常让引用类型“赖着不走”：
- 闭包捕获大对象未释放：内部函数引用了外部作用域的大数组或 DOM 节点，而该函数又被全局变量或事件监听器长期持有
-
全局变量隐式挂载：忘记用
let/const声明，直接赋值largeData = new Array(1e6)，导致绑定到window上 -
DOM 节点脱离但仍被引用：通过
document.getElementById获取节点后移除它，但变量仍指向原节点，且未置为null -
定时器/事件监听器持有闭包：
setInterval或addEventListener的回调内访问了外层大对象，而定时器未清除 - console.log 生产环境残留：打印大型对象（如整个 Vue 实例或响应式数据）会建立强引用，Chrome DevTools 会阻止其回收
快速定位泄漏对象的方法
不用等 OOM，靠浏览器开发者工具就能发现苗头：
- 打开 Memory 面板 → 点击 “Take heap snapshot” 抓取快照，多次操作后对比，看某类对象实例数是否持续增长
- 使用 Allocation instrumentation on timeline 录制交互过程，观察哪些构造函数频繁分配且不释放（重点关注
Array、Object、Closure） - 在快照中筛选 Detached DOM tree，查看是否有大量“已移除但仍有 JS 引用”的节点
- 搜索疑似泄漏关键词，比如
node_modules、组件名、业务模块名，看其关联的闭包或对象是否异常驻留
写代码时的防御性习惯
预防比排查更高效：
- 避免裸写
obj = {...}，优先用const obj = {...}控制作用域 - 所有
addEventListener配套removeEventListener，或用{ once: true } - 定时器统一管理，退出页面或组件销毁时调用
clearInterval/clearTimeout - 缓存类逻辑使用
WeakMap或Map+ 手动清理策略，避免无界增长 - 开发阶段禁用
console.log，上线前确保移除或封装成条件编译
