要真正掌握JavaScript函数的完整生命周期，不能仅仅停留在定义到执行的简单步骤，而应将其视作一条完整的链路：从内存分配、函数执行，到最终被垃圾回收机制清理的整个过程。这个链条的核心，在于理解执行上下文、闭包、引用关系与垃圾回收机制之间如何紧密协作、环环相扣。
函数定义阶段：在内存中生成可执行对象
当JavaScript引擎解析到函数声明或函数表达式（包括箭头函数）时，并不会立即执行代码。引擎的首要任务是在内存堆（heap）中创建一个函数对象。这个对象相当于一份“执行蓝图”，其中包含：
- 函数体的字节码（或经过JIT编译后的机器码）
- 作用域链的初始快照（即对定义时外层词法环境的引用）
length、name等内置属性- 对于非箭头函数，还会隐含一个
prototype对象
这里需要明确：此时函数只是静静地驻留在内存中，既没有执行，也没有创建执行上下文，更未分配任何局部变量空间。
函数调用阶段：执行上下文入栈与作用域激活
每次函数被调用，真正的执行过程才拉开序幕。引擎会立即创建一个全新的执行上下文（Execution Context），并将其压入调用栈（call stack）。整个过程分为两个阶段：
- 创建阶段：初始化变量环境（将
var声明设为undefined）、词法环境（将let/const声明设为uninitialized），并绑定this和arguments（对于非箭头函数）。 - 执行阶段：逐行运行代码，为变量赋值、创建内部函数、访问外层变量。正是在这个阶段，如果函数内部引用了外层词法环境中的变量，就可能为后续的闭包行为埋下伏笔。
那么，执行上下文何时出栈呢？通常是在函数执行完毕后（遇到return）或抛出未捕获的错误后。不过，出栈并不意味着相关的词法环境会立刻被释放——这完全取决于是否存在外部引用仍然“拽着”它不放。
闭包的存在：词法环境持续驻留于堆中
闭包是理解函数生命周期中至关重要的一环。当一个函数返回了另一个函数，并且这个返回的函数在其定义时就访问了外层函数的变量，就会出现一个有趣的现象：即使外层函数的执行上下文早已出栈，它的词法环境（LexicalEnvironment）及其绑定的变量对象，仍然会保留在内存堆中。
来看一个典型的例子：
function createCounter() {
let count = 0;
return () => ++count;
}
const inc = createCounter(); // 此时 createCounter 的执行上下文已出栈
inc(); // 但仍能读写 count —— 因为闭包使 count 所在的词法环境保留在堆中
这种保留并非永久性的。只要还存在对闭包函数（例如例子中的inc）的引用，它所依赖的那层“外壳”词法环境就会一直受到保护，不会被回收。
垃圾回收机制：标记-清除判定引用可达性
最终，决定函数及其关联环境命运的是垃圾回收机制。以V8引擎为例，主要采用标记-清除（Mark-Sweep）策略，并辅以标记-整理（Mark-Compact）。一个函数对象及其关联的词法环境能否被回收，取决于它是否仍然“可达”：
- 是否存在全局引用（例如挂载在
window或globalThis上） - 是否存在活跃执行上下文中的变量引用
- 是否存在闭包函数的引用（这会间接维持对外层词法环境的持有）
- 是否存在定时器、事件监听器、Promise链等异步持有者
一旦所有这些引用都消失（比如执行了inc = null），V8就会在下一个垃圾回收周期中，将这个闭包函数对象及其捕获的词法环境标记为“不可达”，随后将它们从内存中彻底清除。
最后需要明确一点：闭包本身并非“内存泄漏”的代名词。真正的内存泄漏，往往是由于疏忽导致本该释放的引用被长期持有，例如忘记解绑的事件监听器、未清理的缓存，或者误将函数存入全局变量。只有理解了从生到灭的完整路径，才能更好地驾驭JavaScript中的函数与内存管理。
