内联缓存（IC）是V8自动为属性读取生成的优化stub，其高效依赖“三同”：同HiddenClass、同属性名字符串、同访问模式；混用对象形状、动态属性名、方括号访问或getter等均会破坏IC。
内联缓存（Inline Cache，IC）不是你手动开启的开关，而是 V8 在运行时自动为属性读取操作生成的优化 stub。它是否生效、是否高效，完全取决于你写对象访问代码的方式——尤其是 load 操作的**一致性**。
为什么 a.x 有时快 10 倍，有时慢到触发反优化？
V8 的 IC 会为每次 obj.prop 记录两个关键信息：对象的隐藏类（HiddenClass）和该属性在内存中的偏移量（offset）。只有当后续调用传入的对象具有相同 HiddenClass，且访问的是同一属性名，IC 才能直接跳转到内存地址取值。
一旦出现以下任一情况，IC 就会失效或退化为慢路径：
- 同一函数里混用不同形状的对象（比如
{x:1}和{x:1, y:2}） - 属性名拼写不一致（
a.Xvsa.x），哪怕只是大小写差异 - 对象在构造后动态添加/删除属性（
obj.z = 3），导致 HiddenClass 链断裂 - 跨原型链访问（
obj.toString()）且原型被修改过
obj.prop 必须保持“三同”才能稳住 IC
所谓“三同”，是指在同一个函数作用域内、对同一属性名的连续访问，必须确保：
- 同 HiddenClass：所有被访问的对象由同一构造函数/类创建，且属性初始化顺序完全一致
-
同属性名字符串：不能用计算属性
obj[condition ? 'x' : 'y']，也不能靠Object.keys(obj)[0]动态推导 -
同访问模式：不要在
obj.x后突然插入obj?.x或Reflect.get(obj, 'x')—— 这两类访问走的是完全不同路径，会污染 IC 状态
示例对比：
function fastRead(p) {
return p.x + p.y; // ✅ 稳定 IC：两次访问都来自同一 HiddenClass，固定属性名
}
const a = { x: 1, y: 2 };
const b = { x: 3, y: 4 };
fastRead(a); fastRead(b); // 共享高效 IC
function slowRead(p) {
return p.x + p[Object.keys(p)[0]]; // ❌ 第二个访问无法 IC：属性名不固定，且触发 keys() 全量遍历
}
哪些看似无害的操作会悄悄破坏 IC 效果？
这些写法在语义上没问题，但对 V8 来说等于主动关闭 IC 加速：
- 使用
for...in遍历对象并读取属性（IC 不适用于枚举场景） - 把对象作为参数传入多个不同函数，而各函数内部访问的属性名不一致（V8 为每个函数维护独立 IC 表）
- 在热函数中混用
obj.prop和obj['prop']（方括号访问会绕过 IC，走通用 lookup 路径） - 给对象设置 getter：
Object.defineProperty(obj, 'x', { get() { return this._x; } })—— 即使 getter 内部只是返回字段，也会强制走慢路径
真正安全的 getter 替代方案是：用普通属性 + 类封装，靠构造函数保证结构稳定。
IC 的威力藏在重复、单调、可预测里。它不奖励聪明的动态逻辑，只奖励你把对象访问变成一种“机械式”的内存偏移操作。一旦你开始试探引擎边界（比如条件切换属性、运行时拼接 key），V8 就只能放弃推测，退回解释执行——那才是性能断崖的起点。
