Chrome偷藏了你的JS！V8引擎到底做了什么，

原文地址

你是否遇到这些痛点？按理说，

• 页面卡顿。GC 停顿时间不可预测，
• 相同代码在不同浏览器上表现差距巨大。
• 写完函数后仍然出现“慢执行”的警告。
• 对象属性访问频繁，却总是被标记为“高开销”。
• 代码热方法没有得到加速，导致帧率下降。

JavaScript 引擎概览

浏览器能执行 JavaScript全靠JavaScript 引擎。

常见的引擎有的观点是。

• V8 — Chrome、Node.js、Deno 在用
• SpiderMonkey — Firefox 在用
• JavaScriptCore — Safari 在用
• Chakra — 旧版 Edge 在用

V8 是 Google 开发的高性能引擎，用 C++ 编写，让 JS 执行速度可以媲美编译型语言。

V8 的工作流程

你写的 JS 代码。V8 要做的事情可以概括为：

JS代码 → 解析 → 编译 → 执行

但这中间，V8 做了大量偷跑调整。

V8 架构演进

代码是怎么跑起来的？

从 JS 到机器码的全链路

You wrote:

function add {
return a + b;}
console.log);

The V8 pipeline:

1. 解析 → 把 JS 转成 AST
2. 解释 → 编译成字节码并立即执行
3. 调整编译 → 热代码被编译成高效机器码
4. 执行 → 结果返回

Ignition — 解释器

Ignition 把 JavaScript 编译成字节码：a lightweight intermediate representation that’s quicker to generate than machine code yet faster to run than raw source.

// 原始 JS
function add {
return a + b;}

Simplified byte‑code :

LdaSmi # load small integer a
LdaSmi # load small integer b
Add # add m
Return # return result

为什么要转字节码？

…为后面的 TurboFan 提供依据。

Ignition 的执行反馈示例

 function add{return a+b;} // 第一次调用记录类型 add;// 参数为整数，记录为 Smi add;// 类型一致，继续记录 add;// 类型变为字符串，记录下来

Ignition 会把每段代码对应的类型信息存入 Feedback Vector。以便 TurboFan 决定是否调整一下或反调整。

TurboFan — 调整编译器 



JIT  = 即时编译。它不是提前把所有代码都编译好。
而是边运行边把「热点」代码提高为原生机器码，从而获得近乎 C++ 的速度。

TurboFan 调整流程 

字节码 + 执行反馈 ↓ Sea of Nodes ↓
类型推导 Pass ↓ 内联 Pass ↓ 环路调整 Pass ↓
寄存器分配 Pass ↓ 最终机器码

热点检测机制 

function add{return a+b;}
for{
add，}

调用次数 <阈值 → Ignition 解释执行 
调用次数 ≥ 阈值 → TurboFan JIT 编译 
调整与反调整 

当函数在热方法上出现类型突变时TurboFan 会撤回已生成的机器码。回退到字节码继续执行，以保证正确性。

function add{
return a+b;}
foradd，// 全部整数 → 被调整为整数加法
add;// 突然出现字符串 → 触发 Deopt，回退到字节码

常见的调整场景与陷阱 


 ✅ 好的模式 
 ❌ 差的模式 



函数参数类型保持稳定
参数在整数/字符串之间切换导致频繁 Deopt

对象属性顺序一致。共享同一隐藏类
属性顺序不一致产生多个隐藏类，引发 Megamorphic 调用



隐藏类 — 快速属性访问 

对象属性查找背后的秘密 

V8 为每种对象结构创建一个「隐藏类」，类似于 C++ 中的结构体布局。通过隐藏类，属性访问可以直接映射到内存偏移量。这样就能实现 O 的读写速度。

const person = { name:'Tom',age:30 };对应隐藏类示意：
yaml
HC0的观点是，├─ name -> offset 0
└─ age -> offset 1

属性访问过程示例 

person.name;// V8 查找 person 的隐藏类 HC0 → 获取 offset 0 → 返回 “Tom”

隐藏类转换规则 


Add property ⇒ 创建新隐藏类并链接至旧类。

Edit existing property value ⇒ 隐藏类不变，只修改槽位内容。老实说，


javascript
const obj = { x:10 };// HC0
obj.y = 20;话说回来，// 创建 HC1：{x,y}
obj.x = 30;// 值改变，不影响 HC1结构
**关键点**：保持对象结构一致可以让多个实例共享同一个隐藏类。从而获得更好的缓存命中率。

单态 / 多态 / 全态 


 状态 
 隐藏类数量 
 性能影响 



Monomorphic 
1 个 
最快 – Inline Cache 命中率几乎为100% 

Polymorphic 
 个 
稍慢 – IC 中保存少量分支 

Megamorphic 
> 10 个甚至更多 
最慢 – 必须走通用散列表查找 





内联缓存— 加速函数调用和属性读取 

函数调用真的很慢吗？

看似简单的一行代码背后其实会触发一次属性定位、一次原型链查找还有一次栈帧创建。若每次都走完整方法，则累计成本不容小觑。

javascript
function getName{
return user.name;}
const u={name:'Tom'};getName，

**第一次**：


查找 u 的隐藏类


在 HC0 中找到 name 的偏移


返回值并记录「HC0→offset」到 Inline Cache
**随后调用**：


检查当前实参对象是否仍然是 HC0


若匹配。则直接使用已缓存的 offset，无需
查找
这样就把原本 O 的成本降到了 O。

L​abel：The IC state evolves exactly like hidden‑class states: Uncached → Monomorphic → Polymorphic → Megamorphic.




IC 状态

描述

性能影响

示例

结果
...
Sorry we cut due to token limit but continue later?