内联缓存（IC）通过缓存属性查找结果并比对隐藏类实现提速，而非多存数据；其性能取决于对象结构是否统一，单态时最快，多态次之，超态则退化为慢路径。
内联缓存（inline cache, ic）不是靠“多存一份数据”来提速，而是通过记住最近一次属性查找的结果，并在结构一致时跳过全部查找步骤，把原本要走的“找隐藏类→查属性表→算偏移量→取值”压缩成“比对+直接读内存”这一步。
它解决的是动态访问的重复开销
JavaScript 对象没有固定结构，每次 obj.x 都得重新确认：这个对象属于哪个隐藏类？x 在这个类里存在吗？它在内存中第几个字节？这些判断涉及哈希查找、原型链遍历、分支预测失败等高成本操作。尤其在循环或高频函数中反复执行时，这些开销会叠加放大。
IC 的思路很直接：既然上一次刚查过 obj.x，且知道它在隐藏类 A 下偏移量是 16，那只要下个对象也是隐藏类 A，就不用再查——直接从地址 +16 处取值。
提速关键在于“单态稳定”
IC 效果好不好，取决于你用的对象是否结构统一。V8 会为每条属性访问指令维护一个缓存状态：
- 单态（Monomorphic）：只见过一种隐藏类 → 缓存里硬编码了该类和偏移量，下次命中就是纯指针加法，最快
- 多态（Polymorphic）：见过 2–4 种 → 缓存变成小映射表，查表后跳转，仍有明显收益
- 超态（Megamorphic）：类型混杂超过阈值（如 10+ 种不同结构）→ 放弃缓存，退回到通用慢路径
所以高频访问能快 5–10 倍，往往是因为对象批量创建自同一构造函数（如 new User()），字段顺序、有无缺失属性都保持一致，IC 很快进入单态并长期稳定。
哪些写法会让 IC 失效或降级
IC 不是全局智能缓存，它绑定在具体代码位置（比如某行 user.name）。以下任一情况都会触发缓存失效或升级：
- 对象中途添加/删除属性（
obj.newField = 1或delete obj.x），导致隐藏类变更 - 混用不同结构的对象（如同时传入
{id, name}、{_id, fullname}、class User实例） - 用方括号动态访问（
obj[ propName ]），无法在编译期确定属性名，IC 难以稳定 - 访问 getter 属性，每次都要调用函数，IC 只能缓存到 getter 函数本身，不缓存结果
你可以观察 IC 是否生效
V8 提供调试工具辅助验证：
- 启动 Node.js 时加
--trace-ic，运行时会打印 IC 状态变化（如 “monomorphic”、“polymorphic”、“megamorphic”） - 用
%DebugPrint(obj)查看对象当前隐藏类 ID，对比多次创建对象的 ID 是否一致 - 配合
--print-bytecode观察属性访问字节码旁是否生成了 IC 相关 stub
真正影响性能的，从来不是“有没有缓存”，而是对象结构是否可控、访问模式是否收敛。IC 是引擎自动为你搭好的高速通道，前提是你别频繁换车道。
