内联缓存（IC）不优化原生迭代方法本身，而是优化其回调函数的调用点；关键在于回调参数对象结构是否稳定——单态最快，多态次之，超态退化为慢路径。
高频调用原生迭代助手（如 Array.prototype.map、filter、reduce 等）本身不直接参与内联缓存（IC）的优化路径，因为它们是引擎内置函数，其内部属性访问逻辑由 C++ 实现，不走 JS 层的 IC 机制；真正受影响的是你传入的回调函数——它的调用点是否稳定、参数结构是否一致，才决定 IC 能否生效。
回调函数才是内联缓存的关键入口
原生迭代方法只是“调度器”，V8 对它们的调用本身不生成 IC 条目；但每次执行 arr.map(cb) 时，cb 在循环中被反复调用，每个调用点（call site）都会独立建立反馈向量。若 cb 接收的对象类型/结构频繁变化，IC 就会降级：
- 单态：始终传入
{id: 1, name: 'a'}这类固定结构对象 → IC 缓存属性偏移，访问item.id极快 - 多态：有时传
{id: 1}，有时传{id: 2, score: 95}→ IC 查小表，有额外分支开销 - 超态：混入
null、undefined、new Date()等 → IC 失效，每次都要走慢路径查找
避免破坏 IC 稳定性的常见写法
这些看似无害的操作，会让原本可缓存的调用点迅速退化：
- 在回调中动态添加或删除属性：
item.temp = Math.random()或delete item.name - 用不同顺序初始化对象：
{a: 1, b: 2}和{b: 2, a: 1}在多数 V8 版本中仍属不同隐藏类 - 混用构造器实例与字面量：
map(item => item.x)同时接收{x: 1}和new Entity({x: 1}) - 回调内修改原型链：
item.__proto__ = baseProto会强制所有已缓存的 IC 条目失效
验证 IC 是否正常工作的实操方式
不用改业务代码，靠运行时诊断即可确认：
立即学习“Java免费学习笔记（深入）”；
- 启动 Node.js 时加
--trace-ic，观察输出中map: monomorphic是否持续出现；若频繁出现megamorphic，说明结构不稳定 - 在 Chrome DevTools Console 中对典型输入对象执行
%DebugPrint(obj)，比对多个 item 的Map地址是否一致 - 录制 Performance 面板火焰图，若
JSFunction::GetProperty占比异常高，且集中在回调内部，大概率是 IC 未命中导致反复查找
更安全的替代模式
当标准迭代无法保证参数稳定性时，可转向可控性更强的方式：
- 用普通
for循环代替map，手动控制对象访问，避免隐式调用点泛化 - 预处理数据，统一结构后再迭代：
arr.map(normalizeItem).map(cb)，确保cb始终面对同一隐藏类 - 将高频回调提取为独立函数并复用，而非在闭包中动态生成 —— 闭包易导致变量逃逸，干扰 IC 类型反馈
