V8优化class实例的关键在于构造函数中属性是否稳定初始化：属性名、顺序、类型和时机一致时触发快属性布局（≤10个属性存于对象头后），否则退化为慢属性，内存开销高30–50%。
直接看内存表现，关键不是“用了class”，而是实例化后对象的属性结构是否稳定、是否触发快属性布局。V8 对 class 实例的优化完全取决于构造函数中属性的初始化方式——它不区分 class 或 function 构造器，只认属性名、顺序、类型和时机。
快属性布局如何被触发
当一个对象的命名属性数量 ≤ 10（默认值），且所有属性在构造时一次性声明（非动态追加），V8 会把它们存入对象头后的连续内存区域，即“对象内属性”（in-object properties）。这是最快的访问路径，偏移量固定，无需哈希查找。
- ✅ 正确写法：class Point { constructor(x, y) { this.x = x; this.y = y; this.id = 0; } } —— 所有字段在构造函数首行就赋值，顺序一致，类型收敛
- ❌ 危险写法：constructor(x, y) { this.x = x; if (y) this.y = y; } —— 分支导致部分实例缺 y 属性，隐藏类分裂，无法共享快属性布局
- ⚠️ 隐患写法：constructor(x) { this.x = x; }；后续 obj.z = 1 —— 动态添加打破初始结构，强制迁移到“快属性存储区”（external property storage），多一次指针解引用
慢属性何时生效及内存代价
一旦对象进入字典模式（dictionary mode），所有命名属性都以哈希表形式存于独立 chunk 中，此时不再依赖隐藏类迁移链，也不再启用内联缓存。典型触发条件包括：
- 执行 delete obj.prop —— 不可逆降级，即使重赋值也无法恢复快属性
- 同一属性反复赋不同类型值（如 this.count = 1 → this.count = 'done'）—— V8 标记为“多态”，IC 失效，最终可能触发去优化
- 构造后大量动态增删（如 for...in + delete 混用）—— 快属性存储区碎片化，V8 主动切换至慢属性以保稳定性
慢属性的内存开销比快属性高约 30–50%：每个属性额外携带 key 字符串、value、attributes 描述符三元组，且哈希桶存在空间冗余；而快属性仅存 raw value，共享隐藏类中的偏移定义。
定量评估的可行方法
没有 API 直接返回“快/慢属性占比”，但可通过 Chrome DevTools 的 Memory 面板 + 堆快照做有效估算：
- 录制高频实例化过程（如 new Point() × 10⁵），生成堆快照，筛选 constructor 名为 Point 的对象
- 查看单个实例的 “Properties” 区域：若显示 in-object 字样，说明仍处于对象内属性布局；若显示 properties 并指向外部数组，则已退化为快属性存储；若显示 dictionary，即为慢属性
- 导出快照 JSON，统计 __proto__ 指向相同 Map 地址的对象数量 —— 共享隐藏类越多，快属性复用率越高；若 Map 地址高度离散，说明隐藏类分裂严重，快属性命中率下降
高频实例下的典型陷阱
很多 class 设计表面简洁，实则破坏快属性连续性：
- 使用可选参数 + 条件赋值（如 this.tag = options?.tag ?? ''）—— 若 options 经常为 undefined，this.tag 就不会被初始化，导致隐藏类分支
- 继承链中子类覆盖父类属性顺序（Parent ctor 设置 x/y，Child ctor 在 super() 后又设 y/x）—— 即使字段相同，顺序错位也会生成新隐藏类
- class 字段声明（public x = 0）在 V8 10.x+ 已支持，但需注意：该语法等价于在 constructor 内部首行赋值，安全；而 private #x 则走 Symbol 存储，不参与隐藏类，也不进快属性
