写过几年 JavaScript 的人心里多半都有过这个疑问明明这是一门“跑在浏览器里的脚本语言”甚至当年还被不少人当成玩具语言为什么 V8 能把 JS 压榨到接近原生程序的性能而且不光是快它启动还得快、内存还得省同一台机器上几百个页面一起跑谁也不能把内存吃爆。答案就藏在这条链路里AST、字节码、JIT、去优化。V8 的整套设计说白了是一个“翻译官 加速器”的组合翻译官负责把 JS 源码变成机器能理解的中间形式加速器负责在运行过程中发现热点、大胆猜测、疯狂优化。这篇文章我想把这条链路从头到尾拆开讲清楚每一层到底在干什么、为什么这么设计以及这些机制对我们写代码到底有什么影响。适合对 JS 引擎有好奇心的前端开发者也适合想把 Node.js 服务端性能再往下压一压的工程师。不搞玄学全部落到机制本身。1. 先搞明白V8 到底是怎么把 JS 跑起来的1.1 从一行代码到 CPU 指令中间隔了多少层先想一个问题CPU 只认识机器码但 JS 是文本。那一行const sum a b;是怎么变成 CPU 指令的最简单的思路是像 C/C 那样写个编译器一把梭直接把源码编译成机器码。但 JS 的问题在于类型是运行时才确定的。a b到底是整数相加、浮点相加、字符串拼接还是对象隐式转换不到执行的瞬间没人知道。传统静态编译的思路在这条路上直接堵死。所以 V8 的选择是分成两步走。第一步把源码先“读懂”这一步得到的产物叫 AST抽象语法树。AST 本质上是把代码的语法结构变成了一个树状数据每个节点对应一个语法单元比如变量声明、函数调用、二元运算。有了 AST 之后引擎才算真正“看懂”了这段代码。第二步把 AST 转成字节码字节码是给解释器用的中间指令它比 AST 更靠近机器码但又没有绑定到任何具体的 CPU 架构上。V8 的 Ignition 解释器逐条执行这些字节码程序就能跑起来了。如果故事到这里就结束JS 会非常慢。解释器逐条执行指令每条指令加起来还有额外分发开销比机器码慢一个数量级很正常。V8 真正的杀招在于它不会一直这么慢悠悠地解释执行而是边跑边观察哪个函数热起来了就让编译器把它变成真正的机器码。这就是 JIT它的全称是 Just In Time即时编译后面我会展开讲。1.2 为什么 V8 选择“翻译官 加速器”而不是一口气编成机器码为啥不一开始就把所有代码编成机器码其实早期 V8 就是这么干的老版本的 V8 对每个函数直接做全量编译结果有两个问题很现实启动慢、内存大。你想想看一个网页里可能加载了几万行 JS但用户一打开页面真正立即执行的可能就几十个函数。为那些可能永远不执行的函数生成机器码完全就是浪费。所以后续 V8 改成了现在这套“分层编译”的思路先用解释器把代码跑起来同时收集运行时信息等确认哪些函数是热点了再花代价去优化编译。这个思路有点像打仗时的常规部队和特种部队常规部队先整建制压上去机动灵活、部署快发现关键节点后特种部队再针对性地攻坚成本高但战斗力强。要是一开始就把所有资源都堆给特种部队大部分资源就浪费在了根本不重要的方向上。1.3 “翻译官 加速器”这套组合里的几个角色这套体系里有两个绝对核心、两个新角色。绝对核心是 Ignition 和 TurboFan。Ignition 是翻译官负责把 AST 转成字节码并解释执行TurboFan 是加速器负责把热点代码编译成高度优化的机器码。近几年 V8 又加了两个中间角色Sparkplug 和 Maglev。Sparkplug 是一个快速编译器它不做什么深度优化而是快速把字节码“翻译”成机器码省掉解释器本身的分发开销Maglev 则是介于 Sparkplug 和 TurboFan 之间的“轻优化编译器”它比 Sparkplug 做更多优化但比 TurboFan 更快出产物适合那些有一定热度但又不至于让 TurboFan 施展全部功夫的代码。这一整套流水线往深了说非常复杂但你只需要抓住一条主线源码一路被降级翻译最终到机器码翻译过程中伴随大量观测和反馈观测结果决定了哪些代码能走加速通道。接下来我把几个关键环节一个个拆开看。2. 翻译官是怎么工作的AST 到字节码的降级链2.1 第一道工序从源码到 ASTV8 里有“懒人”解析器这一段常被当成理所当然但实际很有门道。V8 拿到源码后先做词法分析把字符串切成 token。比如const sum a b;会被切成const、sum、、a、、b、;这些最小的词法单元。然后语法分析器把这些 token 组合成 AST。听起来直接但 V8 在这里偷了个大懒它把函数区分成“表层解析”和“深度解析”。表层解析就是只看函数的大概外壳知道这里有个函数叫foo但函数体内部是怎么样的、有没有语法错误先不管。只有函数真正被调用的时候V8 才会回过头来做一次完整的深度解析。这个设计很聪明因为大量函数声明了但可能整个会话都不会被调用。如果你写过大型应用就会知道加载阶段的时间很多都花在解析上。V8 用懒解析大幅降低了启动成本。当然代价也明显第一次调用的那一刻函数要临时补做深度解析会卡顿一下。这是启动时间和运行时间的经典取舍V8 选择偏向启动快很合理。2.2 字节码是解释器的“母语”AST 已经足够表达代码结构但它不是用来被“执行”的为了让 Ignition 跑起来AST 要降级成字节码。V8 的字节码是基于寄存器的设计每条指令会明确指出操作数从哪个寄存器读、结果写到哪个寄存器。本来一个a b在 AST 里是个树节点在字节码里就成了类似Add r0, r1, r2这样的线性指令。这不是难度的降低而是一种从“结构”到“步骤”的映射。我拿一个简单函数举例。假设源码是这样function add(a, b) { return a b; }它在 V8 里对应的字节码大概是这样的流程先把参数 a 加载到寄存器把 b 加载到另一个寄存器执行加法指令返回结果。真实字节码指令集不同版本有差异术语和操作数长度也不完全一样但整体思路就是这种栈机器和寄存器机器结合的模型。这里请记住一个关键认知字节码比 AST 节省大量内存一条 Add 指令就占几个字节而 AST 里一个加法表达式节点光是类型信息和子节点指针就要消耗几十字节。2.3 为什么字节码必须存在跨平台和优化的公共底座有人可能会问既然 TurboFan 能把 JS 编成机器码那我不想用解释器还能跨平台吗这里的关键是字节码是一种平台中立的中间表示。它不依赖 x86 还是 ARM也不依赖是 Windows 还是 Linux哪个平台上的 V8 都能用同一套字节码定义然后各自把需要优化的热点代码翻译成对应平台的机器码。这意味着 V8 团队不需要为每个 CPU 架构单独写一套“高级语言到机器码”的编译器只要把面向字节码的优化做好机器码生成部分和平台解耦就行。而且字节码还有一层好处TurboFan 接收的不再是原始 AST 或源码而是结构规整的字节码需要做数据流分析、类型推断、指令选择时操作在同一套中间表示上进行逻辑统一也更容易测试和验证。一句话字节码就是整个体系的“通用语言”。3. 加速器是怎么介入的从解释执行到 JIT 编译3.1 谁来告诉 V8“这个函数值得优化”现在我们到达核心地带了。Ignition 在解释执行的时候不只是傻跑就完事它会偷偷记录很多运行时信息。这些信息存在哪里存在每个函数、每个调用点的 feedback vector 里。什么叫调用点就是你代码里每次执行函数调用的地方都有一个槽位。V8 会在这些槽位里记录这个函数调用时参数是什么类型的返回值的类型是什么属性访问的这个对象它的结构长什么样等一个函数被反复执行执行次数超过阈值之后V8 就会意识到这哥们是热点值得花更多资源去优化。此时 TurboFan 会被唤醒它要做的第一步不是直接生成机器码而是先读取 feedback vector 里存着的类型信息。TurboFan 通过分析这些信息形成猜测然后基于猜测去做优化。注意优化在本质上就是“猜”猜你这个函数未来还会按照过去观察到的模式运行。猜对了性能起飞猜错了就得付出代价这个代价就是后面要讲的去优化。3.2 隐藏类V8 世界里最快的属性访问方式要理解 JIT 为什么能让 JS 变快绕不开隐藏类这个概念V8 里也常叫它 Map 或对象形状。JavaScript 的对象就像动态的字典给你一个对象你随时可以 add、delete 属性。如果属性访问真的每次都在字典里做字符串查找那速度会非常感人。V8 的破解办法是给“结构相同”的对象共享一份隐藏类描述每个属性在隐藏类里对应一个固定的偏移量。对象第一次创建后属性被赋予到固定的存储位置后续访问属性就能像 C 语言结构体访问字段一样直接从偏移量取数据不再做键查找。举个例子假设你有 1 万个结构完全一样的用户对象都只有 name 和 age 两个属性。在 V8 里这 1 万个对象会共享同一个隐藏类每个属性偏移量一致属性访问就能编译成一条内存读取指令。但只要你给其中一个对象额外加一个属性或者删一个属性它的形状就变了V8 必须要给它“换”一个新的隐藏类其背后的优化节奏就被打断了。这也能解释为什么很多 V8 性能优化文章都会强调保持对象形状固定别随意增删属性。3.3 TurboFan 的优化流程TurboFan 拿到反馈信息后进入优化编译流程。它会把字节码转成自己的中间表示然后做一堆优化内联、逃逸分析、消除冗余加载、常量折叠等等。内联是说如果一个函数足够小而且调用次数够多TurboFan 可能直接把被调用函数的代码复制到调用方里面连函数调用本身的开销都省了。逃逸分析是说如果发现一个对象只在函数内部用没有泄漏到外部那这个对象就不需要真的分配在堆上字段可以直接放进寄存器或栈上省掉一次堆分配这在创建大量临时对象的场景下收益非常可观。但别忘了我前面说的这些都是建立在“假设”上的。TurboFan 不是无条件这么做它会在生成的机器码周围插入检查代码来验证这些假设是否还成立。比如 TurboFan 认为a和b都是整数它就会生成add前先检查 a 和 b 是否依然是整数的指令。检查通过直接走快路径一旦检查失败就会跳到去优化的逻辑把执行权交还给解释器放弃当前优化版本。3.4 从 add 函数看 JIT 的完整生命周期回归到例子。你写了个add第一次调用时Ignition 解释执行并在 feedback vector 里记下“这两个参数都是整数”。第 100 次调用时触发 TurboFan 编译。优化的版本里参数类型检查通过后直接执行整数加法指令时间从解释执行的几十纳秒级别降到几个纳秒级别。但如果某次调用忽然传了字符串机器码里的类型检查失败V8 只能去优化回到解释器重新执行。同时 feedback vector 更新记录为“这次出现了新的类型”。下次再想优化TurboFan 就得把这个场景考虑进去生成一个能处理“整数 OR 字符串”的版本或者干脆放弃优化。这里要说一个很反直觉的点JIT 优化不是越复杂越好。TurboFan 会把函数不断上报的类型观察结果纳入考虑但如果一个函数同时出现过两三种大相径庭的类型TurboFan 可能生成包含分支的判断代码或者干脆把这个函数降级为“不值得优化”。代码本身的逻辑一样但运行效率天差地别。这就是为什么同样功能有人写出了每秒几百万次调用还稳稳的代码有人写出来就慢一个数量级。4. 去优化加速器失效时要付出的“代价”4.1 什么叫去优化前面已经几次提到去优化现在彻底把它讲透。去优化Deoptimization指的是 JIT 编译器发现之前编译时的假设不再成立于是废弃当前优化的机器码版本让程序回到解释器继续执行。这个过程不是简单的“这段代码不用了”而是要把整个执行状态“还原”到之前某个能被解释器接管的安全点。V8 在设计优化的机器码时会在关键位置埋好必要的元数据以便在不一致发生的一刻能找到对应的字节码位置重组解释器需要的状态。这个重组过程代价很高往往可以高达毫秒级别。毫秒听起来也没多大但放在热循环里就很恐怖了。假设一个函数每秒钟被调用百万次一次去优化就能让整体吞吐率出现一个肉眼可见的坑而且去优化之后想要再触发优化还要重新收集一轮反馈信息期间一直是用解释执行在跑。这个“坑”很容易被真实业务感知到特别是 Node.js 服务端在某个特定请求路径上如果你偶发传参类型不一致就可能造成周期性性能抖动。4.2 哪些代码最容易把 V8 逼到去优化我把实战里常见的触发场景整理成了一张表每一条都值得记下来对照自己的代码查一遍。触发原因机制说明典型代码形态传参类型不稳定同一函数一会儿整数一会儿字符串TurboFan 的整数加法假设被打破function add(x, y) { return x y }调用时混传 number / string对象形状变动优化代码基于固定隐藏类偏移量新属性或删除属性破坏 Shapeobj.name a后又obj.age 18且这两类对象都热执行调用点出现多种对象类型同一个调用点执行时对象的隐藏类五花八门无法稳定内联tryGetValue(item)一会儿传数组一会儿传对象数组越界或访问稀疏空洞优化器如果假设数组是紧密连续的类型遇到 hole 会触发保护失败arr[5]而 5 位置从未填充arguments 被逃逸使用参数对象被传出函数或变成闭包捕获对象无法用栈分配优化把arguments存进外部数组返回抛出异常带try/catch的区域受到更保守的优化策略影响热点异常路径容易破坏优化热函数内部频繁 throw外层 catch超出内联预算代码体积增长过快TurboFan 停止内联热点关联的函数变成了普通调用热函数越写越长、依赖越来越多看到这张表再对照自己项目里的代码应该能想起不少问题场景。我最常见到的接口数据经过两个不同的校验函数后同一字段前面是字符串后面被当数字做运算整个运算函数被反复打回解释器执行但没人察觉因为功能是正常的慢是慢在细节里。4.3 怎么看到去优化的全过程用 Node 的生命周期标志讲理论不带实操总觉得空落落的。Node.js 里可以直接开 V8 的诊断标志来观察优化和去优化。比如写一个模拟热函数的小脚本用node --trace-opt --trace-deopt跑起来就能在终端看到类似这样的输出哪个函数被编译了、被哪个编译器Sparkplug / Maglev / TurboFan编译以及某次因为什么原因被deoptimize。命令行长这样node --trace-opt --trace-deopt script.js实际输出里会出现函数名、优化器类型及去优化原因。你可以在业务里准备一段最小复现脚本然后用这个标志找出是什么操作把热路径打断了。浏览器端虽然没有完全等价的透明日志但 DevTools 的 Performance 面板抓 profile 时也能看到与脚本编译、优化相关的任务时间。配合内存快照可以判断是否存在对象形状爆炸的问题。4.4 尽量别让代码触发去优化稳定优先级最高给个最实用的总结V8 最不欢迎的就是“不确定性”。它不怕你用新特性不怕你写得花哨就怕你前后不一致。要想让 JIT 发挥最大价值就尽量保证热路径里的类型、形状、调用模式保持稳定。比如一个函数是拿来做数值计算的就在入口处把输入显式转成 number不要一会儿 number 一会儿 string 地传给后面。对象属性能一次建好就一次建好不要把“初始化”和“运行时补充字段”混在一起。这些调整不会让代码变难看但能让 V8 的猜测大概率命中。5. 实操中怎么拿这套机制指导性能优化5.1 写业务代码时直接能用上的几条经验理解 JIT 和去优化之后我对业务代码的整体审美变了。以前写代码只强调可读性、逻辑清晰现在还会额外留心“热路径是否稳定”。具体有几点亲测值得执行。对象初始化时一次性把结构定下来。不要在构造函数里先给三四个属性然后在别处又补两三个。后者会让同一类对象的隐藏类分散成好几种V8 得分别打点记录。数据量小无所谓但你在循环里创建一万个对象还每种形状各不同优化基本上就废了。数组保持同质。JavaScript 的数组其实是很复杂的容器V8 的数组元素也有多种存储模式比如 packed / holey、SMI / Double / 普通元素。一个只存整数的数组V8 能用非常紧凑的方式存储和访问一旦混入字符串数组的表示就得降级甚至后续加了数字也恢复不到原先状态。所以写聚合代码时尽量保证数组里元素类型一致别老想着“反正 JS 数组可以混着放”。函数参数稳定。那些被高频调用的工具函数入口处别让类型飘忽不定。你可以在函数开头做一次轻量转换把参数统一成你预期的类型再往下传。这既是在约束代码也是在帮 V8 反馈信息变得干净。5.2 用“先测量再优化”对抗自动化工具教条网上很多性能优化文章喜欢列出清一色“不要用 try/catch”“不要用闭包”“不要用 arguments”的结论但真正有经验的工程师都知道优化不能只看规则要看具体代码跑在最激进位置的那部分。如果你硬要列一条最重要的优化准则那我选“先测量再优化”。大部分规则只在特定代码结构里有效长期揪着某一条规则死守反而可能把代码改成看不懂的样子且收益为负。我自己的习惯是先确定业务里确确实实存在吞吐量或延迟瓶颈再针对瓶颈函数开 profile。如果 profile 显示瓶颈确实是 JS 代码本身就往 V8 机制方向分析类型稳不稳、对象形状散不散、有没有频繁去优化。如果瓶颈在 IO 或等待资源上那你把 JIT 研究再透也帮不上忙。5.3 常用术语速查表给需要立刻看懂 V8 文章的人把这串术语背下来你再去看 V8 相关的性能文章基本不会再晕。AST 是抽象语法树源码的树形结构表示。字节码是介于 AST 和机器码之间的中间指令也是 Ignition 解释器的执行对象。Ignition 是 V8 的字节码解释器。TurboFan 是 V8 的优化编译器。Sparkplug 和 Maglev 是近几代 V8 里新增的快速编译器与轻量优化编译器用来丰富编译层次。JIT 是即时编译指运行时把热点代码编译为机器码的机制。Feedback Vector 是存储函数反馈信息的向量用来记录每个调用点的类型信息。Hidden Class或 Map / Shape是描述对象属性结构的数据结构决定属性访问能否快路径命中。IC 是内联缓存它根据反馈向量来缓存属性访问和调用点信息减少重复查找。Deopt 是去优化指优化假设失效后回到解释执行的过程。OSR 叫栈上替换是说循环在函数尚未整体优化完的时候也能切入优化版本的机制往往出现在大循环场景里。这套术语本身就是一个知识网络。看到“去优化”就要联想到类型反馈、假设、隐藏类这些上下游概念看到“内联缓存”就要联想到调用点、megamorphic 多态调用这些概念。等你脑子里这个网络成形了再剖析一段性能异常代码思路会清晰得多。5.4 我压箱底的一个调优小技巧最后分享一个精力和收益比极高的动作。当你部署的 Node.js 服务出现周期性耗时尖刺排查不出来原因时去审视那些“看似不起眼但调用次数极高”的短小函数。比如一次性封装了很多逻辑的通用工具函数比如在循环里做类型转换的辅助函数。把里面每次调用都会创建小对象的写法改成直接传参或用固定形状的对象传参再把参数类型入口掰牢。我踩过几次坑之后养成一个习惯所有警告级指标先看函数热路径的类型稳定性再回头看代码结构本身。通过这套方法我曾把一个原本平均每个请求额外多出几次去优化的函数树的耗时压低了将近一半代码没少多少收益却立竿见影。V8 的例子也被我用来提醒团队写 JavaScript 不是只能靠“写得好不好看”来评价引擎对你的代码还有一套隐形的审核标准。一个函数能不能被抬高到最激进的内联和类型优化很大程度取决于你给它喂的东西有多稳定。多用这些知识审视自己的代码往往比加一堆缓存配置来得更直接。这也是我觉得这趟从 AST 一路走到去优化的旅程最值得记住的地方。