内联缓存（IC）失效源于对象隐藏类不一致，导致V8从单态→多态→超态退化，最终放弃缓存、回退慢速查找，并可能触发去优化；常见诱因包括动态增删属性、属性顺序混乱、类型漂移及混用delete。
JS 编译器（如 V8）在处理“多态”属性访问时，并不是真的在运行时“搜索”隐藏类，而是因类型不一致导致内联缓存（IC）失效，被迫退回到慢速查找路径——这才是真正产生开销的地方。
多态访问怎么触发 IC 失效
内联缓存是 V8 加速属性访问的核心机制。它会在第一次访问 obj.name 时，记录下 obj 当前的隐藏类，并把该属性的内存偏移地址缓存下来。后续调用只要对象仍属同一隐藏类，就直接按偏移读取，耗时纳秒级。
但当同一个函数被不同隐藏类的对象反复调用（比如 5 种结构各异的 {name} 对象），V8 的 IC 就会从单态（monomorphic）→ 多态（polymorphic）→ 超多态（megamorphic）。一旦进入超多态，引擎放弃缓存，每次都要：
- 检查对象当前隐藏类
- 查隐藏类中该属性的描述（是否在快属性区、偏移多少、是否需字典查找）
- 若已降级为字典模式，还得做哈希计算和桶遍历
什么操作会制造多态场景
多态本身不是写法错误，而是结构不收敛的信号。常见诱因包括：
- 构造后动态添加属性：一个对象有
.id，另一个没有，却走同一函数逻辑 - 属性顺序混乱：
{x:1, y:2}和{y:2, x:1}生成不同隐藏类，无法共享 IC - 同名属性类型漂移：
obj.count = 1→obj.count = 'done'→ V8 标记该字段为“类型不稳定”，IC 不再信任其偏移 - 混用
delete和赋值：delete obj.flag再obj.flag = true，大概率触发字典模式
影响不只是“慢一点”
多态访问的代价是系统性的：
- 属性访问变慢 2–5 倍：从固定偏移读取退化为哈希表查找
- 触发去优化（deoptimization）：JIT 已编译的高效代码被丢弃，回退到解释执行
- 影响整个调用链：若 A 函数调用 B，B 中发生多态访问，A 也可能被连带去优化
- 阻碍后续优化：例如无法对循环中的对象字段做分配消除（escape analysis）
怎么判断你遇到了这个问题
不能靠猜。开发阶段可借助工具定位：
- Chrome DevTools → Memory 面板 → 堆快照，筛选
Object类型，观察同类对象是否拥有大量不同构造器或属性数差异大 - Node.js 启动时加
--trace-ic，看控制台是否频繁打印LOAD_IC: ... megamorphic - 用
%HasFastProperties(obj)（需开启--allow-natives-syntax）检查对象是否还在快属性模式
