闭包使外部函数的局部变量从栈移至堆内存长期持有，而非栈未释放；变量通过函数对象的[[environment]]属性绑定词法环境，作用域链独立于调用栈存在，由gc按引用关系回收。
闭包让函数执行完后，本该被回收的局部变量依然保留在内存中——这不是因为栈空间没释放，而是变量被移到堆中长期持有。
闭包不占用调用栈，变量实际存在堆内存
调用栈只负责管理函数的执行顺序和生命周期：函数调用时入栈，返回时出栈。栈上只存基本类型值和指向堆的引用。一旦函数执行结束，它的执行上下文（包括栈帧）立刻弹出销毁。
但若内部函数引用了外部函数的变量，JS 引擎会通过逃逸分析识别出这些变量“逃逸”出了当前作用域，于是把它们分配到堆内存，而非栈内存。这样即使 outer() 执行完了、调用栈里早已没有它，inner() 仍能通过闭包引用访问这些堆中的变量。
- 栈内存：存放形参、基础类型局部变量（如 let x = 1）、执行上下文指针——函数返回即清空
- 堆内存：存放闭包捕获的变量、对象、函数体、数组等——由垃圾回收器（GC）按引用关系决定何时回收
- 闭包本质是“函数 + 其词法环境的引用”，这个环境里的变量驻留堆中，与调用栈解耦
调用栈中看不到闭包变量，但作用域链依然有效
每次函数调用都会创建执行上下文，其中包含作用域链。闭包函数 inner() 在定义时就绑定了 outer() 的词法环境，形成一条从 inner → outer → 全局的作用域链。这条链不是靠栈维持的，而是作为内部属性（[[Environment]]）保存在函数对象上。
所以即便 outer() 已退出，inner() 调用时仍能顺着这条预设的作用域链找到堆中的 count 变量：
- outer() 执行时：count 创建于堆，outer 的词法环境记录对它的引用
- inner() 返回并赋值给 counter：counter 持有 inner 函数对象，inner 内部 [[Environment]] 指向 outer 的词法环境
- counter() 调用：引擎查 inner 的 [[Environment]]，再从中读取 count —— 全程不依赖调用栈
闭包导致的内存驻留是可控的，不是栈泄漏
有人误以为“闭包让栈不释放”，其实完全相反：闭包恰恰是因为栈必须及时释放，才被迫把变量搬到堆里。真正的风险不在栈，而在堆——如果闭包长期持有大对象或 DOM 引用，又没被正确释放，就会阻碍 GC 回收，造成内存泄漏。
- 常见隐患：事件监听器中使用闭包引用大型数据，却忘记 removeEventListener
- 安全做法：闭包变量不再需要时，手动置为 null（如 inner._cache = null），帮助 GC 判定可回收
- 现代引擎（如 V8）会优化未逃逸变量，仍放栈中；只有真正被闭包捕获的变量才会升格到堆
闭包与调用栈的关系，核心就一句话：栈管执行流程，堆管数据生命；闭包是堆对栈的“温柔挽留”，不是栈的失职。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
