直接改写__proto__会破坏v8内联缓存（ic）前提，因ic依赖静态不可变原型链；手动赋值触发去稳定化，致隐藏类失效、属性访问退化为慢速查找。
直接改写 __proto__ 不仅无法帮助你理解内联缓存（IC），反而会破坏 V8 的全部优化前提——IC 依赖稳定、不可变的原型链结构，而手动赋值 obj.__proto__ = newProto 会立即触发去稳定化（de-stabilization），使 IC 失效、隐藏类失效、快速属性路径退化为慢速通用查找。
IC 的前提：原型链必须静态且不可变
内联缓存不是“缓存某个属性在哪一层找到”，而是缓存“在某隐藏类下，属性 x 的内存偏移量是多少”。这个偏移量的计算前提是：整条原型链的形状（shape）已被引擎提前固化。V8 只有在原型对象自创建起从未被修改时，才会为继承它的对象生成可复用的隐藏类，并在 a.x 这样的点号访问处建立单态 IC stub。
- 一旦执行
obj.__proto__ = X，当前对象脱离原有隐藏类体系，进入字典模式（Dictionary Mode），后续所有属性访问都绕过 IC - 若修改的是原型对象本身（如
Parent.prototype.z = 1），所有已存在的和新建的子类实例都会失去共享 IC 的能力 -
super.prop能高效运行，正是因为 class 语法天然保证了 super 指向的原型链是编译期确定、运行时不变更的
真正能揭示 IC 工作机制的操作：观察稳定 vs 破坏后的性能差异
不靠改 __proto__，而是通过可控对比，才能看清 IC 如何生效：
- 写一个简单函数
function get(prop, obj) { return obj[prop]; }，反复传入相同结构对象（如{x: 1}），再对比混入{x: 1, y: 2}或null后的执行耗时——--trace-ic会显示从monomorphic退化为megamorphic - 用
%DebugPrint(obj)查看两个对象的 Map 地址是否一致：一致说明共享隐藏类，IC 可复用；不一致则说明结构已分裂 - 把
obj.x和obj['x']放在同一热循环里交替执行，会发现前者逐渐变快、后者始终慢——这不是变量缓存，而是 IC 在点号访问上持续命中
替代方案：用合法方式模拟 IC 的“缓存-命中”逻辑
想理解 IC 的寻址本质，更有效的方式是聚焦它真正优化的环节：
- 属性访问最终转化为“对象基址 + 固定偏移量”——这正是编译语言结构体字段访问的方式；IC 的作用就是把“查偏移量”这一步省掉
- V8 为每个
a.x字节码位置维护一个 IC stub，里面只存两样东西：上次遇到的隐藏类 ID 和 x 在该类下的字节偏移；下次同隐藏类，直接加偏移取值 - 这个过程完全绕过原型链遍历、跳过哈希表查找、不检查
hasOwnProperty，所以比Reflect.get(a, 'x')快 3–5 倍
为什么你不该碰 __proto__ 来“研究”IC
因为 __proto__ 是 V8 明确标记为高危操作的接口：
- 它强制中断整个原型链的稳定性假设，引擎必须立即清空所有相关 IC stub、重置反馈向量、降级对象为字典模式
- Chrome DevTools 中执行
%DebugPrint(obj)会显示DictionaryElements或SlowProperties，这是 IC 彻底失效的明确信号 - 现代最佳实践（class、Object.freeze、构造器初始化）全部指向“让原型链静止”，而非动态干预
