Object.setPrototypeOf 会触发 V8 引擎去优化，导致已编译代码失效并退回解释执行：隐藏类链断裂使属性访问降为哈希查找；内联缓存全部作废；相关函数被标记为不可优化；内置方法特化逻辑崩溃。
Object.setPrototypeOf 会直接触发 JavaScript 引擎（尤其是 V8）的去优化（deoptimization），这不是“稍慢一点”的问题，而是让已编译的高效代码瞬间失效、退回到解释器执行。它的破坏机制是底层且连锁的。
隐藏类链断裂，快属性访问失效
V8 为每个对象动态生成隐藏类（Hidden Class），用以记录属性顺序和内存偏移。一旦调用 Object.setPrototypeOf，引擎必须：
- 立即废弃该对象当前的隐藏类及其所有迁移路径
- 切断已有优化代码对属性位置的预判（例如 obj.x 不再能直接读内存 offset 8）
- 将对象降级为“字典模式”（dictionary mode），后续所有属性访问都需哈希查找，耗时上升数倍
内联缓存（IC）全部作废
引擎在函数中调用 obj.method() 时，会基于原型链缓存方法地址（IC entry）。原型变更后：
- 所有已缓存的 IC 条目失效，下次调用需重新遍历原型链定位方法
- 无法内联调用（inline call），失去消除虚函数调用开销的关键优化
- 即使只改一个对象的原型，只要其他对象共享同一原型，它们的 IC 也可能被连带清空
函数被强制标记为不可优化
若某个函数曾在优化状态下读取过该对象的属性或方法（如 obj.x、obj.toString()、obj instanceof C），V8 就会把它和该对象的隐藏类绑定。原型一改：
- 该函数立刻被标记为 deoptimized，下次执行跳过 JIT 编译，退回解释器模式
- 短期内难以重新优化——引擎需要观察多次稳定调用，而原型已变，无法满足类型一致性要求
- 影响范围不限于单个函数：多个函数共用该对象时，可能批量退化
内置方法特化逻辑崩溃
对数组、日期等内置对象调用 Object.setPrototypeOf，后果更严重：
- Array.prototype.map 等方法依赖特定原型结构做内建优化（如 typed array 快路径）
- 原型链被篡改后，引擎无法确认对象是否仍满足优化前提，直接禁用特化逻辑
- 退回到通用慢路径，性能下降常达 5 倍以上，且部分操作可能意外失败
