变量生命周期本质是栈与堆中“怎么来、怎么活、怎么走”：基本类型存栈，引用类型数据存堆、地址存栈；存活取决于可达性，非时间；全局和隐式全局最难回收；释放即切断所有引用。
变量生命周期从内存角度理解，本质是看它在栈和堆中“怎么来、怎么活、怎么走”。JS 不让你手动管内存，但你得清楚引擎在背后怎么安排——关键不在语法，而在变量值存在哪儿、谁还连着它、什么时候断开。
栈里存值，堆里存数据，地址在栈里
基本类型（number、string、boolean、null、undefined、symbol、bigint）声明即入栈，整个值就放在栈空间里，轻量、直接、快进快出。比如 let count = 100，100 这个数字本身就在栈上。
引用类型（对象、数组、函数、DOM 节点等）则分两步：实际数据存在堆中，栈里只存一个指向堆地址的“小纸条”。比如 let user = { name: "Alice" }，{ name: "Alice" } 存在堆，user 变量在栈里保存的是这个堆位置的地址。
这意味着：
- 栈中变量随作用域结束自动清空（如函数执行完，内部 let/const 声明的变量立刻不可访问）
- 堆中对象不会因函数结束而消失，只要还有变量、属性、闭包或全局引用连着它，它就继续活着
- 多个变量可以指向同一个堆地址（let a = {}; let b = a;），改 a.name 也会影响 b.name
存活与否，只看“能不能被找到”
JS 引擎不靠时间判断变量该不该销毁，而是用可达性分析：从全局对象（浏览器是 window，Node 是 global）、当前调用栈里的变量出发，顺着所有引用链往下找。能走到的对象就是“可达的”，其他一律标记为垃圾。
常见“找不到”的错觉：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 局部变量被函数返回后赋给外部变量，闭包让内部变量持续被引用，它就一直留在堆里
- 事件监听器没用 removeEventListener 解绑，回调函数持有了 DOM 元素或组件实例，导致整块堆内存无法释放
- 定时器里不断往数组 push 数据，而数组被闭包或全局变量持有，内存只会涨不会减
全局变量和隐式全局，是生命周期最长的“钉子户”
在顶层作用域用 var/let/const 声明的变量，会作为属性挂到全局对象下（如 window.myVar），只要页面没关闭，它们就一直占着栈或堆空间。
更危险的是隐式全局：myVar = "oops"（没加任何关键字），不仅污染全局，还让这个变量完全脱离作用域控制，极难被回收。
所以：
- 避免顶层声明大对象或缓存数据，尤其不要长期持有 DOM 节点或大型 JSON
- 模块化开发中，用 export 显式暴露，而不是靠全局变量传递状态
- 调试时可查 window 或 globalThis 属性列表，确认有没有意外残留
不是你忘了删，而是你还连着它
JS 没有 delete 变量的语法，delete 只能删对象属性，不能删 let/const 声明的绑定。所谓“释放”，其实是切断所有引用路径。
主动管理的小动作：
- 组件卸载前，清空定时器（clearTimeout/clearInterval）
- 移除不再需要的事件监听器（尤其动态添加的）
- 大对象用完后，可显式赋值为 null（如 bigData = null），帮助引擎更快识别不可达
- 避免在闭包中无节制捕获外部大对象，优先传必要字段而非整个对象
