如何避免频繁修改 proto 触发 V8 隐藏类失效的痛点

应避免运行时修改原型链以维持V8隐藏类优化：禁用__proto__和Object.setPrototypeOf()；构造阶段固定原型，优先用class语法；原型扩展限初始化阶段，热更新改用组合模式。

频繁修改 proto 会破坏 V8 的隐藏类（Hidden Class）机制，导致对象无法共享结构、失去内联缓存（IC）优化，进而显著降低属性访问和方法调用性能。关键在于：**避免在对象创建后动态改变其原型链结构**。

别在运行时改对象的 __proto__ 或 Object.setPrototypeOf()

这是最直接触发隐藏类失效的操作。V8 一旦发现对象的原型被变更，就会标记该对象“脱轨”（deoptimized），后续所有基于该对象的属性读写都绕过快速路径。

• ❌ 避免：obj.__proto__ = newProto、Object.setPrototypeOf(obj, newProto)
• ✅ 替代方案：若需不同行为，用构造函数或 class 显式定义继承关系，在实例化前确定原型链
• ✅ 若必须动态委托，优先用 Object.create(proto) 创建新对象，而非篡改已有对象原型

构造阶段就固定原型，别靠后期“打补丁”

V8 只对构造过程中稳定建立的原型链做隐藏类推导。如果构造函数里没设好 prototype，而靠后续赋值补上，会导致同构造函数产出的对象拥有不同隐藏类。

• ❌ 错误示范：function A() {} 后再 A.prototype.method = ... —— 虽然合法，但若在实例创建后才添加，已存在的实例不会获得该方法，且新增方法可能引发隐藏类分裂
• ✅ 正确做法：所有原型方法应在构造函数 prototype 定义完成后再创建实例；或使用 ES6 class，语法天然保障声明期固化
• ✅ 小技巧：用 Object.freeze(Constructor.prototype) 防止意外增删，强化结构稳定性

慎用 Object.assign() 和扩展运算符向原型注入属性

向 prototype 上批量添加方法本身不危险，但若在运行时反复执行（如热更新、插件系统），每次修改都会让 V8 认为原型“不稳定”，影响新实例的隐藏类收敛。

• ❌ 动态热补：Object.assign(Foo.prototype, { newMethod() {} }) 在服务运行中多次调用
• ✅ 建议：原型扩展只在模块初始化阶段完成；热更新场景改用组合（composition）或策略模式，避免污染原型
• ✅ 可配合 hasOwnProperty + 显式委托模拟“动态方法”，不触碰原型链

用 class 语法替代旧式构造函数 + 原型赋值

现代 class 语法在编译/解析阶段就锁定方法位置和继承关系，V8 更容易生成稳定的隐藏类序列，也天然阻止运行时对 prototype 的随意修改。

• ✅ class 声明中的方法会被视为“不可配置”（non-configurable），减少意外覆盖风险
• ✅ extends 语法强制在定义时确立原型链，杜绝后期 setPrototypeOf 的诱惑
• ⚠️ 注意：仍要避免在 class 定义后手动改 MyClass.prototype，那同样会破坏优化