JavaScript使用词法作用域而非动态作用域，函数作用域在定义时确定，变量查找沿静态作用域链进行，确保行为可预测、支持闭包与模块化，并为IDE分析和编译优化提供基础。

JavaScript 使用的是词法作用域，不是动态作用域。这个选择不是偶然的，而是为了保证变量查找行为稳定、可预测，也支撑了闭包、模块化等关键特性。

词法作用域：定义时就“写死”了查找路径

函数的作用域链在它被声明（也就是写在代码里的那个位置）时就确定了，和之后怎么调用无关。

• 比如一个函数在全局作用域里定义，哪怕被嵌套函数调用，它依然只认全局变量，不会去查调用者内部的同名变量
• 内部函数能访问外部函数的变量，是因为代码结构上它“写在里面”，这种嵌套关系在写完就固定了
• 引擎执行时，沿着函数定义时形成的“作用域链”一层层向上找，直到全局；找不到就报 ReferenceError

动态作用域：调用时才决定找谁——JS 不走这条路

如果 JavaScript 改用动态作用域，变量值会取决于函数在哪个上下文中被调用，而不是它写在哪。这会让代码极难推理。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 举个典型对比：let x = "global"; function foo() { let x = "local"; bar(); } function bar() { console.log(x); } ——实际输出 "global"，因为 bar 在全局定义；若按动态作用域，它在 foo 里被调用，就该输出 "local"
• 这种行为在 bash 等 shell 脚本语言中存在，但对大型应用来说容易引发隐蔽 bug
• JS 明确拒绝动态作用域，连 eval() 和 with 这类可能破坏词法静态性的机制都被视为危险并 discouraged

为什么词法作用域更适合 JavaScript 的设计目标

它让代码具备静态可分析性，是现代开发体验的基础。

立即学习“Java免费学习笔记（深入）”；

• 编辑器和 IDE 能准确提示变量来源、支持跳转定义、自动补全，都依赖词法作用域的确定性
• 闭包得以成立：返回的函数始终记住它定义时所处的环境，createCounter() 中的 count 就是靠这个存活
• 模块系统（ESM）的导入导出、tree-shaking 等优化，全部建立在“作用域边界在编译期可知”的前提上

别被 this 或 call/apply 带偏了

this 的绑定确实是动态的，但它和作用域是两套独立机制。变量查找永远走词法作用域链，而 this 是运行时根据调用方式决定的对象引用。

• 例如 obj.method() 中 this 指向 obj，但 method 内部读取的变量仍按定义位置查找，不受调用位置影响
• 混淆这两者，是很多作用域相关 bug 的根源