核心是对象创建时结构必须稳定：属性名、顺序、类型一次性确定，v8才能复用隐藏类并启用内联缓存，将属性访问优化为内存偏移计算；动态赋值、顺序错乱、类型混用、delete删除均破坏该稳定性，导致性能下降。
核心是让对象从诞生起就结构稳定——属性名、顺序、类型都保持一致，V8 才能复用隐藏类，启用内联缓存，把 obj.x 变成一次内存偏移计算，而不是动态查找。
用构造函数或 class 一次性声明全部字段
隐藏类在对象创建瞬间就定型。如果先创建空对象再逐个赋值，每一步都可能触发新隐藏类生成，导致 IC（内联缓存）失效、访问变慢。
- ❌ 不推荐：动态拼装
const user = {};
user.id = 123;
user.name = 'Alice';
user.role = 'admin';
——每次赋值都可能切换隐藏类，多个同类对象无法共享结构
- ✅ 推荐：构造时填满
class User {
constructor(id, name, role) {
this.id = id;
this.name = name;
this.role = role;
this.createdAt = Date.now(); // 即使暂不使用，也预留字段
}
}
const u1 = new User(123, 'Alice', 'admin');
const u2 = new User(456, 'Bob', 'user');
——u1 和 u2 共享同一隐藏类，V8 可为 u.x 生成高度优化的机器码
保持属性顺序与初始类型严格统一
两个对象即使属性名相同，只要顺序不同，或某属性首次赋值类型不一致，V8 就视为不同结构，无法复用隐藏类。
- ❌ 顺序混乱 → 隐藏类分裂
const a = { x: 1, y: 2 };
const b = { y: 2, x: 1 };
——x 和 y 顺序颠倒，V8 生成两个隐藏类
- ❌ 类型混用 → 属性被标记为“不稳定”
obj.count = 1;
obj.count = 'done';
——number → string，破坏单态 IC，后续所有 obj.count 访问都降级为字典查找
- ✅ 稳定写法：初始化即定型
this.count = 0; // 始终用数字
this.status = ''; // 始终用字符串
this.isActive = true; // 始终用布尔
避免运行时删改属性，用语义化替代方案
delete 是隐藏类杀手——它不仅改变结构，还可能迫使对象降级到字典模式，属性访问慢 2–5 倍。
- ❌ 删除属性 → 隐藏类重建 + 降级风险
delete user.password;
- ✅ 替代方案一：设为
undefined（温和但非最优） - ✅ 替代方案二：设计时隔离敏感字段（如
user.publicData+user.privateData） - ✅ 替代方案三：用布尔标记位代替物理删除（如
isDeleted: true）
真正需要“逻辑删除”的场景，建议用布尔标记位而非 delete，既保持隐藏类稳定，又符合业务语义。
配合 JIT 编译器：让模型天然适配 TurboFan 优化路径
隐藏类稳定只是基础；要让整个业务模型被 TurboFan 深度优化，还需注意函数调用上下文的一致性：
- 高频使用的模型方法（如
user.validate()、order.calculateTotal()）应是纯函数，无副作用、无this动态绑定、无可选链或方括号访问 - 在循环或 requestAnimationFrame 中反复创建/使用该模型时，确保传入参数类型始终一致（如
new Order(items, taxRate)中items始终是数组，taxRate始终是 number） - 避免在模型内部做
JSON.parse、setTimeout、console.log等打断控制流的操作，否则会阻碍函数被内联和激进优化
一个结构稳定、行为可预测的业务模型，能让 V8 在“温热”阶段（约执行 10–100 次后）快速完成类型反馈收集、隐藏类收敛、函数内联与机器码生成——这才是 JIT 友好的本质。
