普通函数触发内联缓存（ic）优化，箭头函数不触发ic而走词法环境查找路径；前者依赖动态this绑定与调用模式预测，后者恒定读取外层this，无ic开销但无动态绑定能力。
普通函数与箭头函数的寻址耗时差异，**不源于内联缓存（IC）机制本身**，而是因为二者在 JavaScript 引擎（如 V8）中的底层表示和调用路径完全不同——箭头函数根本不会触发传统 IC 优化路径。
内联缓存（IC）只对普通函数生效
IC 是 V8 为加速 动态 this 绑定 + 属性访问 + 方法调用 设计的运行时优化机制。它依赖两个关键前提：
- 函数必须有可预测的调用模式（如
obj.method()频繁出现） - 函数必须具备独立的执行上下文和可缓存的 this 绑定逻辑
普通函数完全满足：每次以 obj.fn() 方式调用时，V8 会记录“此处调用的 this 是 obj，fn 是 X 函数对象”，后续同模式调用直接跳过查表，实现快速寻址。
而箭头函数没有自己的 this，也不参与 this 动态绑定流程。它的“调用”本质是读取外层作用域的词法环境（LexicalEnvironment）——这属于作用域链查找，走的是 静态环境记录（Environment Record）访问路径，与 IC 的热点调用缓存无关。
箭头函数的“寻址”其实是环境变量读取
当你写：
const obj = { name: 'Alice' };
obj.greet = () => console.log(this.name); // this 指向外层（比如 module scope）
V8 编译时就把该箭头函数标记为“词法封闭”，运行时直接从当前函数环境（比如模块级 LexicalEnvironment）中读取 this 值，相当于一次固定偏移量的内存加载（类似读取一个闭包变量），不涉及任何方法分派或 IC 查表。
换句话说：它没有“寻址函数体”的开销，只有“寻址外层 this”的开销——而这个开销恒定、极低，且无法被 IC 加速（也不需要）。
实测对比：IC 对两者影响不对称
在 V8 中启用 --trace-ic 可观察到：
- 对
obj.method()（普通函数）反复调用 → 触发LOAD_IC和CALL_IC，状态从UNINITIALIZED → MONOMORPHIC → POLYMORPHIC - 对
obj.arrow()（箭头函数）反复调用 → 无任何 IC 状态变化日志，引擎始终走CallFunction的通用路径，但实际执行更快（因跳过了 this 绑定和 IC 检查）
这也解释了为什么在高频回调场景（如数组遍历、事件处理器）中，箭头函数常比绑定后的普通函数略快：它省掉了 bind() 生成新函数对象的开销，也绕开了 IC 初始化阶段的延迟。
真正影响性能的关键不是 IC，而是使用方式
如果你误把箭头函数当普通方法挂载在对象上（如开头例子），问题不在“寻址慢”，而在this 永远错位——这时引擎虽快，但逻辑错误，调试成本远高于微秒级耗时差异。
反之，若你在 class 中大量使用 handleClick = () => {...} 类字段箭头函数，V8 会为每个实例单独创建函数对象，导致内存占用上升——这不是 IC 失效，而是闭包膨胀问题。
所以，与其关注“IC 下谁更快”，不如记住：普通函数适合需要动态 this、构造能力、可被 bind/call 控制的场景；箭头函数适合明确继承外层 this、追求简洁回调、避免手动绑定的场景。
