JavaScript执行上下文详解：影响代码运行的关键因素

JavaScript执行上下文远非代码运行时“自然形成”的环境，而是一个严格按规则创建、具有明确生命周期（创建与执行两阶段）的核心对象，它直接掌控this绑定、作用域链构建、变量提升行为、闭包引用机制乃至异步回调中的变量捕获逻辑；从for循环中setTimeout输出重复值的困惑，到箭头函数无this绑定的本质，再到eval在非严格模式下的VO污染风险，所有这些看似零散的JS疑难杂症，根源都深植于执行上下文的创建时机、栈式管理及各阶段行为差异——理解它，才是真正掌握JS运行时行为的关键钥匙。

执行上下文不是“执行时的环境”，而是函数调用时创建的独立作用域容器

很多人误以为执行上下文（Execution Context）是 JS 引擎“运行代码时自然形成的环境”，其实它是一个**严格按规则生成的、有生命周期的对象**。每次调用函数（包括全局代码首次执行），JS 引擎都会新建一个执行上下文，并把它压入执行上下文栈（Execution Context Stack）。这个栈决定了 this、变量查找顺序、arguments 和词法作用域链的起点。

关键点在于：执行上下文不是静态的，它分两个阶段——创建阶段（确定 VO/AO、作用域链、this）和 执行阶段（真正赋值、运行语句）。很多闭包、变量提升、this 绑定异常，都源于混淆了这两个阶段。

为什么 setTimeout 里的 var 变量总输出最后一个值？跟执行上下文的生命周期直接相关

这是典型的“循环 + 异步回调 + 变量提升”三者在执行上下文机制下共同作用的结果。根本原因不是 var 本身，而是：每次循环迭代**复用同一个函数执行上下文的变量对象（VO）**，而 setTimeout 的回调函数在后续事件循环中才执行，此时循环早已结束，i 已被赋值为最终值。

• var i 被提升到当前函数执行上下文的变量对象顶层，整个循环共用一个 i
• 循环体内的 function() { console.log(i); } 是闭包，它捕获的是对 i 的**引用**，而非快照
• 当回调真正执行时，它所在的执行上下文已创建完毕，查找 i 会沿作用域链向上找到外层函数上下文的 VO 中那个已被改写的 i

for (var i = 0; i  console.log(i), 100);
}
// 输出：3, 3, 3

箭头函数没有自己的 this，是因为它根本不创建执行上下文中的 this 绑定

普通函数在创建执行上下文时，会根据调用方式（如 obj.method()、new Fn()、call()）初始化 this 值；而箭头函数**不绑定 this、arguments、super 或 new.target**——它根本不会在自己的执行上下文中设置这些属性，而是直接从外层函数执行上下文的作用域链中向上查找。

• 箭头函数的 this 是定义时所在词法作用域决定的，与调用位置无关
• 它没有 arguments 对象，必须用剩余参数 ...args 替代
• 不能用作构造函数（new 会报 TypeError: xxx is not a constructor），因为它没有 [Construct] 内部方法

eval() 在非严格模式下会污染当前执行上下文的变量对象

eval() 是少数几个能动态修改当前执行上下文变量对象（VO）的行为。在非严格模式下，传入字符串代码若含 var 声明，JS 引擎会将该变量注入到**当前执行上下文的 VO 中**，相当于“就地声明”。

• 这会导致难以追踪的变量泄漏和覆盖问题，比如 eval('var x = 1'); 后，x 突然出现在当前作用域
• 严格模式下，eval 有自己的独立执行上下文，其内部声明的变量不会影响外层 VO
• 现代代码应避免使用 eval()；若必须动态执行，优先用 Function 构造函数（它总是创建新执行上下文，隔离性更好）

"use strict";
eval("var y = 2");
console.log(y); // ReferenceError: y is not defined

执行上下文的真正复杂点不在概念，而在它如何与作用域链、闭包、this 绑定、异步任务队列交织——尤其是多个执行上下文嵌套时，变量查找和 this 分配会同时受多层上下文状态影响，稍不留神就掉进“我以为它在这儿，其实它在那儿”的坑里。

终于介绍完啦！小伙伴们，这篇关于《JavaScript执行上下文详解：影响代码运行的关键因素》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！