词法作用域在代码编写时就确定，取决于函数定义时的嵌套位置而非调用位置；变量查找沿静态作用域链向上进行，闭包是其直接体现，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” 就能看到它捕获的具体变量名和值
- 过度依赖闭包可能造成内存泄漏，尤其在事件监听器或定时器中长期持有大对象时
