从一段数据处理代码说起
假设你正在开发一个前端数据表格组件，需要频繁读取和更新一组行对象。你可能会写出类似下面的代码：
const rows = [];
for (let i = 0; i < 10000; i++) {
rows.push({ id: i, name: `item${i}`, price: i * 10 });
}
function totalPrice(rows) {
let sum = 0;
for (const row of rows) {
sum += row.price;
}
return sum;
}这段代码看起来简单直接，但它的性能表现很大程度上取决于 V8 引擎如何优化属性访问。如果我们在循环中动态添加属性，或者使用 delete 删除属性，性能可能会急剧下降。为什么？因为 V8 依赖隐藏类（HiddenClass）和内联缓存（Inline Caches）来加速属性访问，而这些机制对对象形状非常敏感。
隐藏类：对象形状的标识
在 ECMAScript 规范中，对象被定义为字符串键到属性特性的映射。从规范角度看，所有对象都像字典一样，但 V8 在内部并不总是用字典存储属性，而是根据对象的形状（即属性名及其顺序）采用不同的表示。
每个 V8 对象都有一个隐藏类，它存储了对象的形状信息，包括属性数量、属性名到属性存储索引的映射，以及对象原型的引用。隐藏类类似于面向对象语言中的类，但 JavaScript 是原型语言，无法预先知道类，所以 V8 在运行时动态创建和更新隐藏类。
关键点是：具有相同形状（相同属性、相同顺序）的对象共享同一个隐藏类。例如，上面代码中所有 { id, name, price } 对象都共享同一个隐藏类。V8 通过隐藏类上的描述符数组（DescriptorArray）来记录属性名和值的位置，从而快速定位属性。
内联缓存：记住属性查找结果
内联缓存（IC）是 V8 加速属性访问的关键机制。当代码第一次访问某个对象的属性时，V8 会记录该对象的隐藏类以及属性在属性存储中的偏移量。下次执行同样的代码时，V8 先检查对象的隐藏类是否与缓存的一致，如果一致，就直接使用缓存的偏移量，跳过耗时的属性查找过程。
内联缓存有几种形态：
- 单态（monomorphic）：缓存只记录一种隐藏类，命中率高，性能最好。
- 多态（polymorphic）：缓存记录多种隐藏类，需要额外的类型检查。
- 巨态（megamorphic）：缓存记录很多种隐藏类，性能退化为类似字典查找。
在优化编译器中，如果内联缓存是单态的，编译器可以直接将属性访问内联为内存读取指令，无需任何运行时查找。这就是为什么保持对象形状一致如此重要。
动态添加属性如何破坏优化
回到数据处理的例子。假设你在循环中给行对象动态添加一个 discount 属性：
for (const row of rows) {
row.discount = row.price > 100 ? 0.9 : 1;
}每次添加新属性，V8 都会为对象创建一个新的隐藏类，并更新隐藏类转换树。如果所有对象都按相同顺序添加 discount，它们最终会共享新的隐藏类，内联缓存仍然有效。但如果添加顺序不一致，或者某些对象没有添加，就会产生不同的形状，导致内联缓存失效。
更糟糕的是，如果使用 delete 删除属性，V8 会将对象降级为慢属性（字典模式）。因为删除属性会破坏隐藏类的描述符数组，维护成本太高，V8 干脆放弃快速属性表示。慢属性允许高效的删除和添加，但属性访问速度显著下降。
属性存储的三种形态
V8 中命名属性有三种存储方式：
- 对象内属性（in-object properties）：直接存储在对象本身，访问最快，无需间接层。
- 快属性（fast properties）：存储在独立的属性数组中，通过隐藏类上的描述符数组索引访问，比对象内属性稍慢。
- 慢属性（slow properties）：使用字典存储，属性访问需要查找字典，性能最差。
V8 会根据对象的使用模式自动选择存储方式。如果一个对象频繁添加和删除属性，V8 会将其降级为慢属性，以避免维护隐藏类的开销。但降级是不可逆的，一旦降级，后续访问都会变慢。
内联缓存与原型链
内联缓存不仅用于对象自身的属性，也用于原型链上的属性访问。V8 在缓存原型属性时，会记录实例的形状、原型对象以及属性在原型上的偏移量。如果原型对象被修改（例如改变 Object.prototype），V8 会使相关的内联缓存失效，导致后续访问需要重新查找。
因此，修改 Object.prototype 是一个代价高昂的操作，它会使所有依赖该原型的属性访问缓存失效。同样，使用 delete 删除属性也会影响原型链，因为删除操作可能触发原型链上的属性查找。
实践：保持对象形状一致
基于以上机制，我们可以总结出一些实用的编码建议：
- 在构造函数或对象字面量中一次性初始化所有属性，避免动态添加。
- 不要使用
delete删除属性，如果确实需要可选属性，可以将其设置为null或undefined。 - 避免修改
Object.prototype，这会影响所有对象。 - 对于需要频繁添加属性的场景，考虑使用
Map，因为Map的内部实现不依赖隐藏类。
以下是一个对比示例：
// 不推荐：动态添加属性
const obj1 = {};
obj1.x = 5;
obj1.y = 6;
// 推荐：一次性初始化
const obj2 = { x: 5, y: 6 };替代方案：使用 Map 或数组
当对象形状不稳定时，使用 Map 可能更合适。Map 是专门为频繁增删键值对设计的，其内部实现不依赖隐藏类，因此添加和删除操作的开销更小。但 Map 的属性访问速度通常比快属性对象慢，因为它需要哈希查找。
在数据处理场景中，如果行对象的属性集合是固定的，使用普通对象并保持形状一致是最优选择；如果属性集合动态变化，则使用 Map 更合适。
常见失败模式与诊断
常见的性能陷阱包括：
- 在循环中动态添加属性：导致隐藏类转换，内联缓存失效。
- 使用
delete清理对象：导致对象降级为慢属性。 - 修改原型：导致所有相关内联缓存失效。
诊断这些问题的常用工具是 Chrome DevTools 的 Performance 面板和 V8 的 --trace-ic 标志。通过观察内联缓存的命中率和去优化事件，可以定位性能瓶颈。
这些优化并非 ECMAScript 标准行为
需要强调的是，隐藏类和内联缓存是 V8 的实现细节，并非 ECMAScript 标准要求。其他 JavaScript 引擎（如 SpiderMonkey、JavaScriptCore）也有类似的形状优化，但具体实现和触发条件可能不同。因此，依赖这些优化特性的代码在不同引擎上的表现可能不一致。
作为开发者，我们应该理解这些机制，但不应过度依赖特定引擎的行为。保持代码简洁、避免不必要的动态属性操作，通常是跨引擎的最佳实践。
总结
V8 通过隐藏类跟踪对象形状，通过内联缓存加速属性访问。保持对象形状一致、避免 delete 和原型修改，可以最大化这些优化的效果。在动态属性场景下，考虑使用 Map 作为替代。理解这些机制有助于写出性能可预测的 JavaScript 代码。
对比表格
| 场景 | 对象形状一致 | 动态添加属性 | 使用 delete | 使用 Map |
|---|---|---|---|---|
| 属性访问速度 | 最快（内联缓存命中） | 较慢（隐藏类转换） | 慢（降级为字典） | 中等（哈希查找） |
| 内存开销 | 低（共享隐藏类） | 中（隐藏类树） | 高（字典存储） | 中（哈希表） |
| 适用场景 | 固定属性集合 | 属性集合动态变化 | 不推荐 | 频繁增删键值对 |
流程图：属性访问与去优化
flowchart TD
A[开始] --> B[访问对象属性]
B --> C{内联缓存命中?}
C -->|是| D[直接读取偏移量]
C -->|否| E[查找隐藏类描述符]
E --> F{隐藏类匹配?}
F -->|是| G[更新内联缓存]
F -->|否| H{对象是否慢属性?}
H -->|是| I[字典查找]
H -->|否| J[触发去优化]
J --> K[回到解释器]
K --> L[重新收集类型信息]
L --> M[再次优化]
参考资料
本文内容基于 V8 官方博客《Fast properties in V8》和 Mathias Bynens 的文章《JavaScript engine fundamentals: Shapes and Inline Caches》，以及 V8 文档中关于 Ignition 和 TurboFan 的描述。这些资料提供了隐藏类、内联缓存和属性存储的权威解释。