如何理解词法作用域（Lexical Scope）在函数定义时即确定的特性

词法作用域在代码编写时就确定，取决于函数定义时的嵌套位置而非调用位置；变量查找沿静态作用域链向上进行，闭包是其直接体现，eval和with会破坏该机制。

词法作用域不是运行时决定的，而是写代码时就“拍板”了

函数内部能访问哪些变量，跟它在哪儿被调用完全无关；只取决于它在源码里写在哪一层嵌套结构里。这个规则在你敲下 function 的那一刻就固化了，JS 引擎编译时就记住了它的“出生地”。比如一个函数定义在全局，那它永远只向上查全局作用域；哪怕 later 被传进另一个函数里执行，也不会因此获得那个函数的局部变量访问权。

foo 在哪定义，就决定了它的作用域链起点

作用域链不是按调用栈动态生成的，而是沿着代码物理嵌套层级静态构建的。每次变量查找都从当前函数作用域开始，没找到就跳到它定义时的外层作用域，再外层……直到 window 或 globalThis。

• 嵌套函数能访问外层函数的变量，是因为定义位置就在里面，不是因为“被调用了”
• 把函数赋值给变量、作为参数传出去、塞进数组或对象，都不改变它的原始作用域链
• eval 和 with 会破坏词法作用域的静态性，应避免使用

常见误判：以为调用位置会影响变量查找

典型错误是看到 bar 调用了 foo，就以为 foo 能读到 bar 内部的 value。但实际输出是全局的 1，因为 foo 定义在全局，它的作用域链里根本没有 bar 的局部作用域。

var value = 1;function foo() { console.log(value); }function bar() {  var value = 2;  foo(); // 输出 1，不是 2}

闭包是词法作用域最直接的证据

闭包之所以能“记住”外层变量，正是因为函数体和它定义时的词法环境被绑定在一起。即使外层函数执行结束、执行上下文销毁，只要闭包还活着，那些自由变量就仍被保留在内存中。

• 每个闭包实例共享同一份外层变量引用（循环中用 let 或 IIFE 才能避免常见陷阱）
• 调试时看 Chrome DevTools 的 “Scope” 面板，展开 “Closure” 就能看到它捕获的具体变量名和值
• 过度依赖闭包可能造成内存泄漏，尤其在事件监听器或定时器中长期持有大对象时

真正难把握的是嵌套过深时的作用域链推演——人脑容易混淆“定义位置”和“调用路径”，而 JS 引擎从不犯这种错。写代码时多问一句：“这个函数是在哪一行、哪个花括号块里写的？”，比猜“它现在在谁里面跑”靠谱得多。