object.setprototypeof 在高频读写对象上引发 jit 降级，导致隐藏类断裂、内联缓存失效、函数去优化及内置方法特化崩溃，性能下降可达 3–5 倍。
Object.setPrototypeOf 在高频读写密集型对象上造成的 JIT 降级，不是“变慢一点”，而是让引擎主动放弃优化——它触发的是底层机制的连锁失效，而非单点开销。
隐藏类断裂：快路径直接消失
V8 为高频访问对象生成隐藏类，把 obj.x 编译成类似“从偏移量 8 读取”的机器指令。一旦调用 Object.setPrototypeOf，引擎必须：
- 立即废弃该对象当前隐藏类及其所有已编译代码
- 将对象标记为“字典模式”（dictionary mode），后续所有属性访问退化为哈希查找
- 无法再对 obj.x 做内联缓存，每次读写都走通用慢路径
内联缓存失效：方法调用失去特化能力
引擎在 obj.method() 第一次调用时，会基于原型链缓存方法地址（IC entry）。原型被改后：
- 所有已缓存的 IC 条目作废，下次调用需重新遍历原型链查找
- 无法内联方法体，失去消除虚调用、常量传播等关键优化
- 若 method 是箭头函数或绑定函数，还可能因 this 绑定逻辑变化进一步干扰优化
函数去优化：影响范围远超目标对象
只要某个已 JIT 编译的函数曾访问过该对象（哪怕只读一次属性），就会被标记为 deoptimized：
- 下次执行直接回落到解释器，性能可能下降 3–5 倍
- 即使函数本身没再调用，只要在调用栈中出现过，就可能被连带拖累
- 多个高频函数共用同一对象（如渲染循环中的 state 对象）时，去优化呈扩散效应
内置方法特化崩溃：数组/日期等场景雪上加霜
对高频使用的数组或 Date 实例调用 Object.setPrototypeOf，还会破坏引擎对内置方法的硬编码优化：
- Array.prototype.map 等方法依赖原型链结构做类型特化，改写后退回到通用迭代路径
- Date.prototype.getTime 可能失去内联展开，每次调用都多一层间接跳转
- 引擎甚至可能拒绝某些操作（如对已改原型的数组调用 Array.isArray 返回 false）
