本文通过具体代码示例，深入解析为何必须先调用 g() 才能安全执行 f()，核心在于函数赋值的执行时机与作用域链的形成机制，而非抽象的“执行上下文”概念。
本文通过具体代码示例，深入解析为何必须先调用 `g()` 才能安全执行 `f()`，核心在于函数赋值的执行时机与作用域链的形成机制，而非抽象的“执行上下文”概念。
在你提供的代码中：
let f;
const g = function () {
const a = 23;
f = function () {
console.log(a * 2); // 46
};
};
g();
f();f 并非“天生存在”，而是一个被动态赋值的变量引用。初始声明 let f; 仅创建了一个未初始化（undefined）的绑定，此时 f 指向 undefined，若在此时调用 f()，会抛出 TypeError: f is not a function。
真正关键的一步发生在 g() 被调用时：
- 函数 g 执行，内部创建局部变量 a = 23；
- 紧接着执行 f = function () { console.log(a * 2); } —— 这是一次普通的变量赋值操作；
- 此时 f 才被赋予一个新函数对象，且该函数封闭（captures）了 g 执行时的词法环境，即能访问 a。这就是闭包：函数与其定义时所处词法作用域的组合。
因此，f 的“诞生”严格依赖于 g() 的执行——不是因为 f 在 g 内部“出生”，而是因为 f 的值（即那个闭包函数）直到 g 运行时才被写入。
立即学习“Java免费学习笔记（深入）”；
? 类比理解（如答案所示）：
let f = 2;
function g() {
f = 100; // 简单赋值，无闭包
}
console.log(f); // 输出 2 —— g 尚未执行
g();
console.log(f); // 输出 100 —— 赋值已发生同理，在原例中，f = function(){...} 就是这样一个赋值语句。它不因函数声明提前（hoisting）而提前生效——let 声明的变量存在暂时性死区（TDZ），且赋值操作本身必须显式执行。
✅ 正确顺序不可颠倒：
// ❌ 错误：f 仍为 undefined // f(); // TypeError! // g(); // ✅ 正确：先执行 g，完成 f 的赋值与闭包绑定 g(); f(); // 46
⚠️ 注意事项：
- 闭包的本质是函数 + 其定义时的词法作用域，但闭包函数对象本身需被创建并赋值后才可调用；
- const g = function(){...} 中的 g 是常量引用，但 g 内部对 f 的赋值完全合法（f 是 let 声明，可重新赋值）；
- 若将 f 改为 const f，则首次赋值后无法再修改，但本例中 f 需动态绑定，故 let 是合理选择。
总结：这不是“执行上下文”的玄学，而是清晰的执行顺序与赋值语义问题——f() 可调用的前提，是 f 已被赋予一个函数值；而该赋值动作，恰好发生在 g() 的运行过程中。理解这一点，便抓住了闭包落地的关键环节。
