隐藏类通过为结构一致的对象生成轻量级类模板，将属性访问优化为内存偏移计算，而非哈希查找或原型链遍历；它不优化原型链本身，只加速自有属性访问，并与原型链正交协同。
JavaScript 引擎对原型链的优化，核心不在“链”本身，而在于对象结构的可预测性——隐藏类（Hidden Classes）正是为此诞生。它不是为原型链设计的补丁，而是绕过动态性瓶颈的底层机制：把原本无法静态确定的对象布局，用运行时生成的、轻量级的“类模板”来建模，从而让属性访问从哈希查找回归到类似静态语言的偏移量计算。
隐藏类如何替代原型链中的低效查找
原型链本身不被 V8 直接优化；真正被加速的是**对象自有属性**的访问路径。当一个对象反复以相同顺序添加属性（如 this.x = 1; this.y = 2;），V8 会为其生成一串连续的隐藏类 C0 → C1 → C2，每个类精确记录属性名与内存偏移量。后续同结构对象复用该链，属性读写就变成单条指令加法运算（base + offset），不再需要遍历原型链或哈希查找。
- 原型方法调用仍走原型链，但隐藏类让
obj.method()中的obj.method这一步极快——因为method是自有属性还是原型属性，已在隐藏类中预判并缓存 - 若对象结构混乱（比如不同实例增删属性顺序不一），V8 无法复用隐藏类，就会退化为字典模式，此时所有属性访问都变慢，原型链查找压力反而更大
- 构造函数中统一初始化字段（
this.a = a; this.b = b;）比创建后零散赋值更易触发隐藏类复用
隐藏类与原型继承的协同关系
隐藏类和原型链是正交机制：前者管对象“长什么样”，后者管“能做什么”。它们在 V8 中分工明确又自然衔接。
- 构造函数的
prototype对象也有自己的隐藏类，用于加速对原型方法的访问（如Array.prototype.push的查找） - 子类实例的隐藏类只描述自身属性布局，其 [[Prototype]] 仍指向父类 prototype，方法调用靠原型链兜底，但内联缓存（IC）会记住“这个隐藏类 + 这个属性名 → 原型上的哪个函数”，实现快速委托
- ES6 class 并未改变这套逻辑，只是让构造函数+原型赋值更规范，间接提升了隐藏类稳定性和复用率
破坏隐藏类稳定的常见操作
这些行为看似无害，实则直接切断隐藏类优化链，迫使对象进入低速模式：
立即学习“Java免费学习笔记（深入）”；
-
delete obj.prop：强制切换至字典模式，且不可逆；即使再赋值，对象也维持慢路径 - 混用属性类型：
obj.x = 1后又obj.x = "hello"，可能触发去优化（deoptimization），尤其在热点函数中 - 条件分支中漏赋属性：
if (flag) obj.a = 1，导致部分实例缺少字段，隐藏类分裂 - 使用
Object.assign({}, obj)或展开运算符复制对象，新对象需重新构建隐藏类链，无法继承原对象的优化状态
现代实践建议：不写 delete，预设字段
与其事后删除，不如初始就定义完整结构：
- 构造函数里统一初始化所有可能用到的字段，哪怕暂时为
null或undefined - 用布尔标志或状态字段控制逻辑可见性，例如
isArchived: true替代删掉archivedAt - 避免在热代码路径中动态增删属性；批量变更可用
Object.defineProperties配合固定顺序 - 用
console.log(obj)在 Chrome DevTools 中观察对象是否显示 “Fast properties” —— 这是隐藏类生效的直观提示
