动态修改原型（如Object.setPrototypeOf或__proto__赋值）会立即触发V8去优化，丢弃已编译机器码并回退到解释执行；仅当后续多次调用且原型稳定、类型一致时，才可能重新优化。
动态修改原型（如用 Object.setPrototypeOf 或赋值 __proto__）几乎**立即触发引擎重新优化流程**，准确说是触发去优化（deoptimization），而非“重新优化”。V8等现代引擎不会在修改后立刻生成新优化代码，而是先丢弃已有的高效机器码，退回到解释执行或低效编译版本；只有后续多次调用且运行态稳定时，才可能再次尝试优化。
哪些操作会直接导致去优化
以下行为只要发生一次，就足以让 V8 废弃当前对象及其相关函数的优化代码：
-
调用
Object.setPrototypeOf(obj, newProto)：对象的 [[Prototype]] 被重写，隐藏类链断裂，所有基于原形状的内联缓存失效 -
给对象赋值
obj.__proto__ = newProto：语义等价于 setPrototypeOf，同样破坏隐藏类稳定性 -
在已优化函数中访问该对象的任意属性或方法：只要函数曾对这个对象做过属性读取（
obj.x）、方法调用（obj.method()）或instanceof判断，该函数就会被标记为需去优化 - 多个对象共享同一原型，其中任一对象被改原型：V8 会保守地使所有依赖该原型的优化代码失效，防止类型假设错乱
去优化不是“暂停”，而是性能断崖
它不是暂时慢一点，而是带来连锁反应：
- 已 JIT 编译的函数被强制回退到解释器模式，首次重执行明显变慢
- 若该函数是热点函数（如动画帧、事件处理器、数据处理循环），反复触发会导致持续卡顿
- 内建方法（如
Array.prototype.map）的特化版本也会失效，后续调用失去向量化或内联优势 - DevTools 的 Performance 面板中会出现密集的
deoptimize标记帧，火焰图出现异常宽幅的“锯齿”
什么情况下引擎可能“再优化”回来
去优化后，并不意味着永远无法恢复。但前提是：
立即学习“Java免费学习笔记（深入）”；
- 对象原型不再变动，且保持稳定至少数次调用（通常 >10 次）
- 访问该对象的函数参数类型、返回值、属性访问模式保持一致
- 没有其他干扰因素（如
eval、with、未捕获异常等）抑制优化 - V8 收集到足够“类型反馈（type feedback）”，确认当前形态可安全假设
注意：即使恢复优化，新生成的代码也是基于修改后的原型结构，和原始版本无关——相当于重建了一套隐藏类体系。
真正安全的替代时机
如果必须切换行为，唯一可接受的“修改原型”时机是：
- 对象刚创建、尚未被任何优化函数访问过（例如工厂函数内部，返回前设置原型）
- 仅用于 polyfill 或环境适配，且目标对象生命周期极短、调用频次极低
- 在非热路径上一次性使用，且明确接受性能代价（如 CLI 工具初始化阶段）
除此之外，都应优先选择 Object.create(proto)、组合委托、Proxy 或状态子类等不扰动原型链的方式。
