JavaScript函数生命周期详解：从内存分配到垃圾回收

要深入理解JavaScript函数的生命周期，不能仅关注定义与执行，而应将其视为一个完整的链条：从内存分配、执行，到最终被垃圾回收机制清理。整个过程的核心，在于执行上下文、闭包、引用关系与垃圾回收机制如何紧密协作。

函数定义：在内存中生成可执行对象

当JavaScript引擎解析到函数声明或函数表达式（包括箭头函数）时，并不会立即执行。引擎首先会在内存堆中创建一个函数对象。这个对象如同一份“执行蓝图”，其中包含：

• 函数体的字节码（或经过JIT编译后的机器码）
• 作用域链的初始快照（即对定义时外层词法环境的引用）
• length、name等内置属性
• 对于非箭头函数，还会隐含一个prototype对象

关键点在于：此时函数仅存在于内存中，尚未运行，也未创建执行上下文或分配局部变量空间。

函数调用：执行上下文入栈与作用域激活

每次函数被调用时，过程才真正开始。引擎会立即创建一个全新的执行上下文，并将其压入调用栈。这一过程可分为两个阶段：

• 创建阶段：初始化变量环境（将var声明设为undefined）、词法环境（将let/const声明设为uninitialized），并绑定this和arguments（针对非箭头函数）。
• 执行阶段：逐行执行代码，为变量赋值、创建内部函数、访问外层变量。在此阶段，如果函数内部引用了外层词法环境中的变量，就可能为后续闭包的形成奠定基础。

执行上下文通常在函数执行完毕（return）或抛出未捕获的错误后出栈。但出栈并不意味着相关词法环境会立即释放——这完全取决于是否存在外部引用仍维持着对它的访问。

闭包存在：词法环境持续驻留于堆内存

闭包是理解函数生命周期的关键环节。当一个函数返回了另一个函数，且该返回函数在定义时访问了外层函数的变量，便会产生一个现象：即使外层函数的执行上下文已出栈，其词法环境及绑定的变量对象仍会保留在内存堆中。

以下是一个典型示例：

function createCounter() {
  let count = 0;
  return () => ++count;
}
const inc = createCounter(); // 此时 createCounter 的执行上下文已出栈
inc(); // 但仍能读写 count —— 因为闭包使 count 所在的词法环境保留在堆中

这种保留并非永久。只要闭包函数（如示例中的inc）仍被引用，它所依赖的外层词法环境就会受到保护，不会被回收。

垃圾回收：通过标记-清除判定引用可达性

最终，函数及其相关环境的命运由垃圾回收机制决定。以V8引擎为例，主要采用标记-清除策略，并辅以标记-整理。一个函数对象及其关联的词法环境能否被回收，取决于其是否仍为“可达”：

• 是否存在全局引用（例如被挂载在window或globalThis上）
• 是否存在活跃执行上下文中的变量引用
• 是否存在闭包函数的引用（这会间接维持对外层词法环境的持有）
• 是否存在定时器、事件监听器、Promise链等异步持有者

一旦所有这些引用均消失（例如执行inc = null），V8将在下一个垃圾回收周期中，将该闭包函数对象及其捕获的词法环境标记为“不可达”，随后从内存中清除。

需要明确的是：闭包本身并非“内存泄漏”的同义词。真正的内存泄漏往往源于疏忽导致本该释放的引用被长期持有，例如未解绑的事件监听器、未清理的缓存，或误将函数存入全局变量。理解函数从创建到回收的完整路径，有助于更好地驾驭JavaScript中的函数与内存管理。