词法作用域在代码解析的词法分析阶段即已确定，由函数定义位置而非调用位置决定；引擎通过token分割、ast构建和[[environment]]静态绑定建立作用域链，变量查找严格遵循“自身→外层→全局”路径，遮蔽关系与执行时机无关。
词法作用域不是运行时“猜出来”的，而是在代码被解析的最初阶段——词法分析时就已锁定。它不看函数怎么调用、在哪执行，只认代码写在哪一层嵌套里。
词法分析阶段就定死作用域结构
JavaScript 引擎（如 V8）一拿到源码，立刻开始词法分析：把代码切分成一个个 token，比如 function、let、变量名、花括号等。这个过程不执行任何逻辑，纯粹“读结构”。
- 遇到 function outer() { ... }，引擎标记：这里开启一个新作用域，父级就是当前所在作用域（通常是全局）
- 若 function inner() { ... } 写在 outer 函数体内部，引擎当场确认：inner 的词法父级就是 outer 的作用域
- 所有 let/const/var 声明，按其出现的位置，直接登记进对应层级的作用域记录中
[[Environment]] 引用在定义时就绑定
每个函数在语法树（AST）生成后，引擎会为其分配一个隐式内部属性 [[Environment]]，它指向函数诞生那一刻所处的词法环境。这个链接关系是静态写死的，不是运行时推导出来的。
- 比如 function makeGreeting(name) { let msg = 'Hello'; return () => console.log(msg); }，箭头函数一被定义，它的 [[Environment]] 就绑定了 makeGreeting 的作用域
- 哪怕 makeGreeting 执行完、上下文销毁了，只要返回的函数还活着，它依然能访问 msg 和 name
- 变量查找走的“自己→外层→全局”路径，本质就是顺着这条编译期建好的链向上跳
遮蔽关系由位置决定，和执行顺序无关
同名变量谁生效、哪个会被读到，完全取决于嵌套深度和声明位置。这种关系在你敲下代码的那一刻就确定了，跟后续怎么调用、延迟多久执行都没关系。
- let x = 1; function foo() { let x = 2; console.log(x); } 中，foo 内部一定输出 2，因为编译时已确认内层 x 遮蔽了外层
- 哪怕 foo() 是通过 setTimeout 或跨文件导入后才调用，结果也不会变
- 这种静态可预测性，让 ESLint、IDE 补全、类型检查工具能在编辑时就准确提示变量来源
为什么禁用 eval 和 with？
JavaScript 明确限制某些语法，就是为了守住词法作用域的静态可分析性：
- eval() 会在运行时动态执行字符串代码，可能插入新变量，导致作用域无法在编译期建模
- with 会临时把对象属性注入作用域链顶层，彻底打乱“位置决定可见性”的规则
- 现代严格模式下，这两个特性基本被禁用，正是为了确保作用域结构从书写到执行全程稳定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
