JavaScript函数生命周期始于定义时生成函数对象并存入堆，经历调用时创建执行上下文、闭包维持词法环境驻留，最终由GC基于标记-清除机制在无任何引用时回收。
JavaScript 函数的生命周期，不是从“写完函数”开始，而是从它被定义、执行、脱离作用域，直到内存被回收的完整链条。理解这个过程，关键在于看清执行上下文、闭包、引用关系和垃圾回收机制如何协同作用。
函数定义：内存中生成可执行对象
当 JS 引擎解析到 function declaration 或 function expression（包括箭头函数）时，并不会立即执行，而是创建一个函数对象，存入内存堆（heap）。该对象包含：
– 函数体字节码（或 JIT 编译后的机器码）
– 作用域链的初始快照（即词法环境的外层引用）
– length、name 等属性
– 对于非箭头函数，还隐含 prototype 对象
注意：此时函数尚未运行，不产生执行上下文，也不分配局部变量空间。
函数调用：执行上下文入栈与作用域激活
每次调用函数，引擎都会创建一个新的执行上下文（Execution Context），压入调用栈（call stack）：
立即学习“Java免费学习笔记（深入）”；
- 创建阶段：初始化变量环境（var 声明设为
undefined）、词法环境（let/const 设为uninitialized），绑定this、arguments（非箭头函数） - 执行阶段：逐行执行，为变量赋值、创建内部函数、访问外层变量——此时若引用了外层词法环境中的变量，就可能形成闭包
- 出栈时机：函数返回（return）或抛出未捕获错误后，当前执行上下文被弹出栈；但其词法环境是否被释放，取决于是否有外部引用
闭包存在：词法环境持续驻留堆中
当函数返回另一个函数，且该返回函数在定义时就访问了外层函数的变量，JS 引擎会保留外层函数的词法环境（LexicalEnvironment）及其绑定的变量对象，即使外层函数已执行完毕、执行上下文早已出栈。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
例如：
function createCounter() {<br> let count = 0;<br> return () => ++count;<br>}<br>const inc = createCounter(); // 此时 createCounter 执行上下文已出栈<br>inc(); // 仍能读写 count —— 因为闭包使 count 所在的词法环境保留在堆中
这种保留不是永久的。只要存在对闭包函数的引用（如 inc），它所依赖的外层词法环境就不会被回收。
垃圾回收：标记-清除判定引用可达性
V8 使用标记-清除（Mark-Sweep）为主、辅以标记-整理（Mark-Compact）的策略回收内存。函数对象及其关联的词法环境能否被回收，取决于：
- 是否存在全局引用（如挂载在
window或globalThis上） - 是否存在活跃执行上下文中的变量引用
- 是否存在闭包函数的引用（间接维持对外层词法环境的持有）
- 是否存在定时器、事件监听器、Promise 链等异步持有者
一旦所有引用消失（比如 inc = null），V8 在下一次垃圾回收周期中会将该闭包函数对象及它所捕获的词法环境一并标记为不可达，随后清除。
注意：闭包本身不是“内存泄漏”，只有当本该释放的引用因疏忽而长期存在（如未解绑事件、缓存未清理、全局变量误存函数）时，才导致内存无法回收。
