块作用域绑定与Declarative Record关联及JS绑定解析顺序问询

示例代码 #

//global code: GC
const x=20; //BD_GC_X
{
//block code: BC
    console.log(x); //BC_X
    const x=10; //BD_BC_X
}

修正后理解 #

• BD_GC_X处的x绑定关联到全局执行上下文的词法环境（记为LE_GC）→ 声明式记录（记为DR_GC）
• BD_BC_X处的x绑定关联到块级执行上下文的词法环境（记为LE_BC）→ 声明式记录（记为DR_BC）
• 声明式记录DR_BC的[[OuterEnv]]引用指向声明式记录DR_GC

问题 #

若上述理解正确，请问在BC_X处访问x时，JavaScript是否会优先查找DR_BC再查找DR_GC？若是，JavaScript是如何实现优先查找DR_BC的？

解答 #

你的理解是正确的，在BC_X处访问x时，JavaScript确实会优先查找当前块级上下文的DR_BC，再去外层的DR_GC查找——不过要注意，这段代码实际运行时会抛出**暂时性死区（TDZ）**错误，因为在块级内const x的初始化语句之前就访问了x，但这并不影响我们分析变量查找顺序的核心逻辑。

具体实现逻辑如下：

1. 词法作用域链的查找顺序：JavaScript的变量查找严格遵循「词法作用域链」规则，每次访问变量时，都会从当前执行上下文对应的词法环境（此处即LE_BC关联的DR_BC）开始查找。
2. 声明式记录的绑定检查：声明式记录内部维护着一个变量绑定表，当查找变量时，会先检查当前记录的绑定表中是否存在目标变量的条目——只要有声明条目（const x在进入块级作用域时就已经被纳入DR_BC的绑定表，只是还未完成赋值），就会立即停止向外层的作用域查找。
3. 暂时性死区的触发逻辑：这也是示例代码报错的原因——虽然DR_BC中已经存在x的绑定，但在const x=10完成初始化之前访问该变量，会触发暂时性死区的错误，而不会继续去外层的DR_GC查找全局的x。

总结来说，JavaScript实现优先查找当前作用域声明式记录的核心是：变量查找从当前作用域的词法环境开始，逐层向外遍历作用域链，一旦在当前作用域的声明式记录中找到变量绑定（无论是否初始化），就终止查找流程。

内容的提问来源于stack exchange，提问作者sql_dummy