隐藏类在动态追加属性时失效，因v8需频繁创建新隐藏类并迁移对象，形成查找开销大的过渡链；若出现delete、属性顺序不一致或类型变更，更会强制降级至慢2–5倍的字典模式。
隐藏类为什么会在动态追加属性时失效
V8 为每个对象关联一个隐藏类（Hidden Class），它本质是描述对象“形状”的元数据：包括有哪些属性、顺序如何、是否可写等。当用 obj.x = 1 动态添加属性时，V8 必须创建新隐藏类并迁移对象指针；再加 obj.y = 2，又触发一次迁移。连续多次追加，就会形成隐藏类链（transition chain），每次属性访问都要顺着链查找，开销陡增。
更严重的是，一旦出现以下任一情况，V8 会直接放弃隐藏类机制，把对象降级到字典模式（dictionary mode）：
-
delete obj.x—— 强制切换，不可逆 - 属性添加顺序不一致（
{a:1,b:2}和{b:2,a:1}不共享隐藏类） - 中途修改属性类型（如先赋
obj.x = 42，再赋obj.x = 'hello'）
字典模式下，属性访问退化为哈希表查找，实测慢 2–5 倍，且无法启用内联缓存（IC）。
构造函数中一次性声明所有属性才是稳定解
最可靠的方式，是在对象诞生之初就“定型”——所有属性名、顺序、初始值都明确落在构造逻辑里。这样 V8 能复用同一隐藏类，后续实例的属性读写就能走 IC 快路径。
推荐写法示例：
class Point {
constructor(x, y, z = 0) {
this.x = x; // ✅ 顺序固定，无空缺
this.y = y;
this.z = z;
}
}
const p1 = new Point(1, 2);
const p2 = new Point(3, 4); // p1 和 p2 共享隐藏类
反例对比：
-
const obj = {};→obj.x = 1;→obj.y = 2;：触发两次隐藏类变更 -
const a = {x:1}; a.y = 2;与const b = {y:2, x:1};：结构相同但顺序不同，隐藏类不兼容
预填充 + null 占位比 delete 更安全
如果业务上确实需要“逻辑删除”某个字段（比如表单校验临时屏蔽某属性），不要用 delete obj.field —— 它是隐藏类杀手。改用显式赋 null 或 undefined，对象仍保留在快属性模式（fast properties mode）。
若初始化时不确定某些字段是否存在，但知道最大可能结构，可提前占位：
// ✅ 预留字段，保持形状稳定
function createItem(id, name) {
return {
id,
name,
tags: null, // 占位，避免后期动态添加
metadata: null, // 同上
};
}
这种写法让 V8 在首次创建时就生成完整隐藏类，后续即使只用部分字段，也不会破坏结构一致性。
怎么确认你的对象掉进字典模式了
V8 没有公开 API 直接暴露隐藏类状态，但可通过 %HasFastProperties(obj)（需开启 --allow-natives-syntax）在调试环境检测：
const obj = {};
obj.a = 1;
obj.b = 2;
%HasFastProperties(obj); // true
delete obj.a;
%HasFastProperties(obj); // false ← 已进字典模式
生产环境没法用这个，所以关键还是守住初始化规范：所有对象结构必须在构造阶段拍板，别指望运行时“灵活补丁”。真正复杂的动态键场景，该换 Map 就换，别硬撑对象。
