内联缓存（ic）是v8自动为点号属性访问（a.x）生成的优化机制，依赖隐藏类与属性名完全一致；方括号访问（a['x']）、动态属性名、getter等均会破坏ic，导致性能下降3–5倍。
直接结论：内联缓存（IC）不是你能“启用”的功能，而是 V8 在你写法稳定时自动生效的底层加速器；只要避免破坏隐藏类一致性，a.x 在热路径中可比 a['x'] 快 3–5 倍。
为什么 a.x 比 a['x'] 快得多
方括号访问（a['x']）强制走通用属性查找路径，绕过内联缓存；而点号访问（a.x）才可能触发 IC 的单态优化——前提是对象结构和访问模式完全一致。V8 为每个 a.x 字节码位置维护一个 IC stub，里面只存“上次遇到的隐藏类 + x 的内存偏移量”。下次同位置、同隐藏类、同属性名，就直接跳地址取值，省掉整个原型链遍历和属性表哈希查找。
常见错误现象：console.log(obj.name) 在循环里跑得慢，但把 obj.name 提前赋给变量再用，性能反而提升——这不是变量缓存的作用，而是因为多次 obj.name 访问被 IC 稳定加速了；而一旦中间夹杂一次 obj['name']，IC 就退化为多态甚至超态，后续所有 obj.name 都变慢。
- IC 只对字面量属性名（
a.x、a.y）有效，不支持计算属性（a[cond ? 'x' : 'y']） - 同一函数内混用
a.x和Reflect.get(a, 'x')，会污染该位置的 IC 状态 - 使用
for...in遍历时读属性，IC 完全不参与——那是枚举路径，走的是完全不同的逻辑
如何让对象结构稳住隐藏类
隐藏类变更 = IC 重置。V8 把对象初始化过程看作“类定义”，哪怕只是顺序或类型微调，都会生成新隐藏类，导致之前积累的 IC 失效。
使用场景：构造大量同构对象（如解析 JSON 列表、渲染数据项），或高频调用的工具函数（如 sumItems(items) 内部反复读 item.price）。
- 一次性声明全部属性：
{ id, name, price }✅；不要先{ id: 1 }，再obj.name = 'a'❌ - 严格固定属性顺序：始终
{ x, y, z }，而非有时{ y, x, z } - 避免
delete obj.prop或临时添加obj.temp = 1—— 这会让对象进入字典模式，IC 彻底失效 - 数值属性尽量不用字符串键：
obj['123']被当 elements 处理，obj['id_123']才算 properties，二者 IC 不互通
哪些看似安全的操作实际会破坏 IC
这些写法在语法和功能上完全正确，但对 V8 来说等于主动关闭加速开关。
参数差异：IC 是 per-site（每个代码位置独立维护）+ per-function（不同函数即使逻辑相同，IC 也不共享）。所以 processA(obj) 里用 obj.x，processB(obj) 里也用 obj.x，两个函数的 IC 表互不影响。
- 在热函数中穿插可选链：
obj?.x和obj.x走不同 stub，混合使用会让 IC 升级为多态，命中率骤降 - 给对象加 getter：
Object.defineProperty(obj, 'x', { get() { return this._x; } })→ 后续所有obj.x都走 getter 路径，IC 失效 - 用
Object.assign({}, a, b)合并对象：结果对象的隐藏类与 a、b 都不同，IC 无法复用 - 使用
with或eval：V8 直接禁用 IC，因为作用域不可静态推断
预热与验证 IC 是否生效
V8 不会为冷代码立即生成高效 IC；首次执行走慢路径，几次后才收敛到单态。你可以主动预热，但更关键的是验证是否真稳住了。
性能影响：未预热的热函数前 10–20 次调用可能比稳定后慢 2–3 倍；若 IC 长期卡在多态，性能回落约 40%；超态则基本无加速收益。
- 简单预热：在应用启动时，用典型对象调用目标函数 3–5 次，例如
renderItem({ id: 1, name: 'test' });执行几轮 - 验证方法：Chrome DevTools → Performance 面板录制运行 → 查看热点函数的 “V8.IC” 事件，状态为
monomorphic表示已稳住 - 注意：
console.time()测不准 IC 效果，因 console 本身开销大；应测纯计算路径，如arr.map(x => x.a + x.b)
真正难控制的不是“怎么写快”，而是“怎么不写慢”——IC 对不一致极其敏感，一个 delete、一次 obj[computedKey]、一行 obj?.x，都可能让之前几十万次调用积累的优化瞬间归零。稳定性比技巧更重要。
