执行上下文是javascript代码执行的“临时工作台”，分为全局、函数、eval三种类型；每个上下文包含this绑定、变量环境（含提升机制）和作用域链，按调用栈后进先出管理，支撑变量提升、闭包、作用域等核心特性。
JavaScript 执行上下文，可以通俗理解为“代码正在使用的临时工作台”。
它就像一个专属工位，每次运行代码都得先搭好这个台子
你写一行 let x = 5，JS 引擎不会直接执行，而是先检查：“这段代码在哪儿跑？”——如果在最外层，就搭一个全局工位；如果在函数里，就立刻新建一个函数工位，专供这次调用使用。每个工位彼此隔离，互不干扰，哪怕同一个函数被调用十次，也会有十个独立工位。
每个工位自带三样标配：this 指向、变量清单、找变量的路线图
– this 指向：工位刚搭好时就定死——全局工位里 this 是 window（浏览器）或 global（Node），函数工位里则看谁“叫”了它（比如 obj.fn() 中 this 就是 obj）
– 变量清单（词法环境 + 变量环境）：把所有 var、let、const 声明和函数声明提前记下来，但 let/const 还不能用（暂时性死区），var 则已设为 undefined
– 找变量的路线图（作用域链）：从当前工位开始查，找不到就往上一级工位问，一直问到全局工位为止。闭包的本质，就是内层工位把外层工位的路线图“悄悄存了下来”。
工位不是静止的，而是按顺序叠成一座“调用栈”
– 页面一打开，自动搭起最底层的全局工位
– 调用函数时，新工位压在栈顶，变成当前活跃工位
– 函数执行完，顶部工位立刻拆掉，控制权交还给下一层
– 整个过程像叠盒子：进函数就加盒，出函数就去盒，永远只操作最上面那个
为什么需要这个机制？它解决的实际问题很具体
– 解释“为什么能先用函数再声明”：函数声明在创建阶段就被记入工位清单了
– 解释“为什么 console.log(a) 不报错却输出 undefined”：var a 已提升到清单里，只是还没赋值
– 解释“为什么内层函数能访问外层变量”：靠的是作用域链这条“向上问路”的通道
– 解释“为什么两个同名变量不冲突”：它们根本不在同一个工位里
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
