近日，JavaScript开发者社区围绕其底层执行机制展开新一轮热议。作为一门单线程、非阻塞、异步并发的脚本语言，JS的执行原理长期被视为进阶前端开发的“第一道门槛”。不少开发者坦言，即便能熟练编写代码，对“代码究竟如何被引擎执行”仍是一知半解。为此，我们梳理了JS执行机制中的三个核心概念——执行上下文、调用栈与编译流程，助你从底层逻辑读懂这门语言的运行之道。
执行上下文：代码的“运行环境”
任何一段JS代码在执行前，都会被引擎构建一个“执行上下文”（Execution Context）。通俗来说，它相当于代码的“运行环境容器”，内部存储了变量、函数声明、作用域链以及this指向等信息。最新的ECMAScript规范将其分为三种类型：全局执行上下文（首次加载脚本时创建）、函数执行上下文（每次函数调用时创建）以及eval执行上下文（极少使用）。
值得注意的是，JS引擎采用“词法环境”（Lexical Environment）来追踪变量绑定。当代码进入一个上下文时，引擎会先完成“创建阶段”：建立作用域链、确定this值、将函数声明与变量声明提升（Hoisting）并初始化为undefined。随后进入“执行阶段”，逐行运行代码并更新变量值。正是这一机制导致了开发者常遇到的“变量提升”现象——看似未定义的变量在声明前就能被引用，返回undefined而非报错。
调用栈：函数的“排队调度员”
如果说执行上下文是每个代码块的“私人办公室”，那么调用栈（Call Stack）就是管理所有办公室的“调度中枢”。由于JS是单线程语言，同一时间只能处理一个任务，调用栈便负责记录当前正在执行的函数以及等待返回的函数调用序列。
当引擎遇到一个函数调用时，会创建一个新的函数执行上下文并压入栈顶；函数执行完毕后，该上下文从栈顶弹出，控制权交回上一个上下文。如果嵌套调用过深，栈空间被耗尽，便会抛出经典的“Maximum call stack size exceeded”错误——常见于递归未设置终止条件时。调用栈的LIFO（后进先出）特性，决定了JS中后调用的函数反而先执行完毕，也解释了为何深层嵌套的异步回调容易造成“栈溢出”风险。
编译流程：从源码到机器指令的“翻译官”
JS并非纯粹的解释型语言，现代V8引擎（Chrome、Node.js）已全面采用“即时编译”技术。其编译流程大致分三步：解析（Parsing）、解释（Interpretation）与优化编译（Optimizing Compilation）。
首先，词法分析器将源码拆解为Token流，语法分析器据此构建抽象语法树（AST）。随后，Ignition解释器将AST转化为字节码，并开始逐条执行。当某段代码被多次执行（称为“热代码”），TurboFan编译器会将其编译为优化的机器代码，大幅提升性能。若优化假设失效（如变量类型突变），引擎会执行“去优化”（Deoptimization），退回字节码执行。这种“先解释后编译”的渐进式策略，兼顾了启动速度与运行效率。
工程师视角：理解机制，避免踩坑
面对异步编程等常见场景，掌握执行机制能有效规避“踩坑”。例如，setTimeout的回调函数会被放入任务队列，只有在当前调用栈清空后，事件循环才会将其推入栈中执行。这解释了为什么即便延时设为0，回调也不会立即执行——必须等待主代码块执行完毕。
此外，理解编译优化对性能调优至关重要。保持函数参数类型稳定、避免动态改变对象结构（如使用类而非字面量）、优先使用局部变量等做法，都有助于Js引擎生成更高效的机器码。
从执行上下文的创建管理，到调用栈的调度机制，再到编译流程的即时优化，JS执行机制环环相扣。对于开发者而言，深入理解这些底层原理，不仅能提升调试能力，更能写出更健壮、高效的代码。正如Stack Overflow联合创始人Jeff Atwood所言：“我们使用高级语言，却永远无法完全摆脱对底层原理的敬畏。”